Feature: prefer tectonic-biber as the biber executable

[bryango]

This PR provides a proposal to finally tackle #893.

• When an executable called tectonic-biber is found, either in the current working directory or in $PATH, prefer that as the biber executable instead of biber. Since V2 CLI: Add external commands #1103, the tectonic-biber override can also be invoked with tectonic -X biber.
• Add test for tectonic-biber with cleanups. In particular, biber tests in tests/executable are refactored to reduce
  duplication.

I tried my best to document things in the tectonic book, but I'm a terrible writer so there is definitely room for improvement!

[pkgw]

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 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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 46.42%. Comparing base (78fd977) to head (307d676).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1166      +/-   ##
==========================================
+ Coverage   46.41%   46.42%   +0.01%     
==========================================
  Files         176      176              
  Lines       65118    65136      +18     
==========================================
+ Hits        30222    30242      +20     
+ Misses      34896    34894       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bryango]

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.

Yes, Nix is precisely like that! Everything is defined in the local flake.{nix,lock} (or in the old days, {default,shell}.nix); everything is isolated by default unless one explicitly chooses to "nix profile install" it to the global profile. For me, Nix is basically managing system level dependencies in the Cargo way.

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

environment = <kind>

... where 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.

This is an interesting idea! Perhaps an easier way to implement this is to accept a shell command to activate / source the environment, e.g. environment = conda activate or environment = nix develop. I bet Pixi has something similar. Basically this tells Tectonic to invoke some other tools to set up the environment, then re-run itself within it.

[pkgw]

This is an interesting idea! Perhaps an easier way to implement this is to accept a shell command to activate / source the environment, e.g. environment = conda activate or environment = nix develop. I bet Pixi has something similar. Basically this tells Tectonic to invoke some other tools to set up the environment, then re-run itself within it.

My intuition is that a bit tighter integration could be helpful; e.g. it would be nice for Tectonic to know how to run (e.g.) conda create to install the environment if that needs to be done. (I'd like it to be the case that you can download a Zip file with a Tectonic.toml at the top, unpack it, and build the document with a single, reliable command.) But I agree that a totally bare-bones approach along the lines of

environment = { customActivation: "conda activate" }

seems like it could work.

[thangleiter]

I came here after finally figuring out how to address #893 (new tectonic user; did no realize the version mismatch originated from tectonic using texlive's biber, which in my case was 2024 and therefore did not match the bundled biblatex).

This patch works for me, but 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.