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

❌ Patch coverage is 92.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.12%. Comparing base (96be4fb) to head (52a000d).
⚠️ Report is 28 commits behind head on master.

Files with missing lines	Patch %	Lines
src/driver.rs	92.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1166      +/-   ##
==========================================
- Coverage   28.93%   28.12%   -0.82%     
==========================================
  Files         266      266              
  Lines      178909   202430   +23521     
  Branches   178909   202430   +23521     
==========================================
+ Hits        51774    56928    +5154     
- Misses      54496    64142    +9646     
- Partials    72639    81360    +8721     

Components	Coverage Δ
tectonic	50.89% <92.00%> (+0.34%)	⬆️
bridge_core	34.71% <ø> (+0.48%)	⬆️
bridge_flate	38.82% <ø> (ø)
bridge_fontconfig	83.06% <ø> (-0.37%)	⬇️
bridge_freetype2	92.00% <ø> (ø)
bridge_graphite2	∅ <ø> (∅)
bridge_harfbuzz	∅ <ø> (∅)
bridge_icu	∅ <ø> (∅)
bridge_png	100.00% <ø> (ø)
bundles	34.43% <ø> (ø)
cfg_support	94.84% <ø> (ø)
dep_support	0.00% <ø> (ø)
docmodel	84.09% <ø> (ø)
engine_bibtex	64.32% <ø> (ø)
engine_spx2html	0.00% <ø> (ø)
engine_xdvipdfmx	55.58% <ø> (-9.01%)	⬇️
engine_xetex	35.28% <ø> (-0.46%)	⬇️
errors	47.61% <ø> (ø)
geturl	27.16% <ø> (ø)
io_base	76.04% <ø> (ø)
pdf_io	14.31% <ø> (+0.14%)	⬆️
status_base	71.76% <ø> (ø)
xdv	0.00% <ø> (ø)
xetex_format	22.80% <ø> (ø)
xetex_layout	42.81% <ø> (-3.47%)	⬇️

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

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

[hughesjs]

Having taken a year away from Acadaemia, and thus LaTex, it's a shame to see that this issue still persists when it seems as though there's a perfectly cromulent solution

[CraftSpider]

Eventually, we'd like to replace this with #1304, but lets not let perfect be the enemy of good.