Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

output dir problems #659

Open
bnmnetp opened this issue Dec 24, 2023 · 6 comments
Open

output dir problems #659

bnmnetp opened this issue Dec 24, 2023 · 6 comments

Comments

@bnmnetp
Copy link
Contributor

bnmnetp commented Dec 24, 2023

As I understand it, you can set an @output-dir on the project. (https://pretextbook.org/doc/guide/html/processing-CLI.html#cli-project-manifest-13)
Individual targets can also set @output-dir

Unfortunately if the target sets output-dir it is relative to the project output-dir. For runestone this is not the desired behavior. Runestone wants the output to be in published/document-id where published is a child of the root directory of the project.

Do I need to set my @output-dir for runestone to be ../published/foo That seems to work but is not very intuitive.

@StevenClontz
Copy link
Member

StevenClontz commented Dec 24, 2023

I'd suggest this pattern:

p = Project.parse()
p.output_dir = Path(".")
if p.has_target("runestone"):
    t = p.get_target("runestone")
else:
    t = p.get_target()  # default/top target
t.output_dir = Path(f"published/{DOCUMENT_ID}")

This should work regardless of the author's decisions on how to organize their project

@StevenClontz
Copy link
Member

Updated above - let me know if this covers your use-case so I can close this or investigate further.

@oscarlevin
Copy link
Member

In case someone wanted to set all this in their project.ptx file, they could also have project/@output-dir = "." and then have @output-dir set to whatever they like on their individual targets.

But if you are rolling your own script, then Steven's suggestion is the way to go.

@bnmnetp
Copy link
Contributor Author

bnmnetp commented Dec 26, 2023

Right now I'm still using subprocess to run pretext. I will start to look at replacing that by just using the Project api.

@bnmnetp
Copy link
Contributor Author

bnmnetp commented Jan 26, 2024

I had forgotten about this conversation and just spent a few hours trying to get APEX to build with a V2.0 project file. The old file was there so it appeared that it was failing to update the files. My own memory is to blame for not recalling this discussion.

However I think one thing might help users who are working with the project file in an editor if the defaults for @source, @Publication and @output-dir were made explicit in the project file. (https://peps.python.org/pep-0020/)

The project file for APEX has no value set at the project level and has @output-dir set to output/target everywhere. So I'm not the only one who is confused.

@StevenClontz
Copy link
Member

This is where the Rubyist in me peeks out: Convention Over Configuration

The problem is that some folks have overconfigured their projects to meet esoteric preferences, rather than adopting (or adapting to) conventional defaults when possible. I don't believe this is a significant issue with newer projects, because they simply use the conventions we've established and things Just Work. I wouldn't be excited to encourage new users to deviate from convention by giving them an overly complicated default project file.

In the case of APEX, the solution is to fix their project.ptx by deleting a bunch of unnecessary configuration. I've proposed this at APEXCalculus/APEXCalculusPTX#278

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants