Environment Support

[CraftSpider]

From #1166 (comment):

To go on a moderate tangent ... I have been thinking that maybe a good solution for the biber problem, and other issues I see farther down the line, is to provide some lightweight integration with various package managers as you mention here. This would be most useful for systems where packages can be installed, and their associated environments can be activated, very "locally"; I don't know if Nix is like that.

The idea is that V2 Tectonic.toml file could support a directive like:

environment = <kind>

... where <kind> might be something like "nix", "venv", "nodejs", or "pixi". The last of these (Pixi) is a Conda-based system which explicitly targets local configuration and install, which is exactly what we would want for reproducibility, and it looks like it would be a great fit for this use case. Perhaps Nix would be as well. Tectonic would only have to integrate with any of these in a lighweight way: basically to be able to set up its executable search path for shell-escape operations.

There is also some more discussion on that PR. Basically, we want a way for Tectonic to integrate with the environment to better manage tools where we might require specific versions. Invoke some environment setup, then put itself in that new environment. This would hopefully remove the need for 'hacks' like the tectonic-biber search.

[bryango]

Also reasonable suggestion from thangleiter in #1166 (comment)

I'd like to suggest including the paths specified in Tectonic.toml's extra_paths key of the [doc] table on top of $CWD and $PATH. My project is version-controlled, and it makes sense to me to include all dependencies that are not handled automatically by the bundle there.

For instance, I have a git submodule set up with the class I'm using under root/resources/kaobook and point there with extra_paths = ["resources/kaobook"]. I seems natural to me to also put tectonic-biber in root/resources/tectonic-biber.

[pkgw]

Adding a few miscellaneous updates here ... I continue to think that this is / will be a really important capability to have. Besides biber there are things like pdf2svg, web bundlers for HTML output, and one day maybe (ab)using external package managers to allow people to upgrade TeX dependencies in a managed way (e.g. automatically search node_modules/*/share/tectonic/ for inputs).

And I've been continuing to use Pixi and am more and more convinced that it's probably the ideal tool for this. Some relevant discussion here. It's written in Rust and so elements of it could even be integrated directly into Tectonic, but I suspect that it would probably be best to have Tectonic execute an external pixi executable. (Maybe have Tectonic auto-fetch the executable and save it locally if needed, even?!)

For things like extra_paths in Tectonic.toml, what I would like is to enforce some kind of containment so that in principle one could write some sort of tectonic package command that would take a Tectonic.toml project, bundle it all up into a Zip file, and you would be guaranteed that if you unpackaged it on a new machine it would build identically. Or at least, have the ability to enforce this — maybe warn about constructs that break containment by default, unless the user specifically indicates that they don't care about such things. You can imagine plenty of use cases where it would be convenient for real users to not rigorously enforce this.