Provide `output.path` dictionary entry in `Tectonic.toml`

[mskblackbelt]

As far as I can tell, the v1 interface allows one to specify a different directory for the output. All I can seem to do with the v2 interface and Tectonic.toml is change the name of the output directory contained within ./build. I propose that the output dictionary should have an additional item, path, where the user can specify a different path for the final output (PDF, in this case).

[pkgw]

Thanks for your suggestion! So, the current V2 model is heavily inspired by the Rust/Cargo framework, which is definitely oriented around the idea that it's helpful to have the outputs appearing in a predictable, standardized location, and that if you want them to end up somewhere else, you should basically just copy them. Can you say a bit more about the use case that you have in mind for custom output paths?

I should also say that I'm hopeful that the V2 "document model", with its Rust/Cargo style, can be a good fit for a lot of documents, but it's definitely still a work-in-progress. I don't want to take the Cargo.toml analogy too far so I'm always interested to explore the use cases that I didn't think of.

[mskblackbelt]

My current proposed use involves writing up procedures for chemistry labs. I'd like to use tectonic -X build to compile the latex and place the output file in the root directory (one level above the individual lab folders), such that all of the output PDFs are sitting in the root directory, but all of the source files are broken into individual folders.

You may be correct that putting together a proper build script and adding a copy operation at the end is better, but I'm not yet at that level of complexity… I still tend to use individual tools and haven't gotten to gluing them all together into one comprehensive solution. I like the idea of having an option for output.path, just so I have fewer duplicate files and operations, but I also understand that I might be an edge case.

[pkgw]

@mskblackbelt Yeah, I think my recommendation for your use case would be to do something outside of Tectonic. It wouldn't be too hard to implement your idea, I think, but it would a piece of complexity to Tectonic's interface (construed broadly) that surrounding tools and systems would all have to pay a penalty for. And there would be some mild security implications to worry about: if you're processing an untrusted Tectonic.toml document, you don't want the program to be creating outputs in surprising places.

Some possibilities that I'd suggest for your use case:

• Script the builds + copies with ninja or make or just a shell script (although the V2 interface doesn't currently emit dependency info nearly as nicely as I'd like)
• Create symbolic links from your toplevel to the build files, if your OS supports that

(If you're familiar with make but not Ninja, I highly recommend the latter — it takes a little bit of getting used to but is just much more elegant to use than make, plus speedy and scalable)