[katexochen]

No description provided.

[martinpitt]

The "env shebang" commit is fine of course. But the "use host python" is a rather big hack IMHO:

• The action command line only has python3, so buck can't detect and rebuild things if the host interpreter changes. This breaks cache consistency, including the remote cache.
• There's no check for a minimum version. The bootstrapping currently requires 3.14, or 3.12 with zstd.
• Also, overlap: tine.python_interpreter already lets a project point the toolchain at a target of its own. The new flag skips the target and falls back to PATH.
• This does not work where tine runs the bootstrapped python on the host, like for ty or PYTHON_TEST_INTERPRETER.
• Host stuff like sitecustomize and PYTHONPATH leak into the build.

I assume this is about running tine in NixOS. Is it an option for you to use nix-ld ? (programs.nix-ld.enable). That's meant for exactly this situation.

An alternative might be to pin a musl build/loader in addition to Python, and invoke it as ld-musl-x86_64.so.1 bin/python3.14. That would actually improve hermeticity compared to today.

This is also undocumented, and untested. It could at least have a single test that enables this option, in a new isolation dir, and builds a small target. In umockdev I run CI in a nix container which is also reasonably cheap.

[katexochen]

• The action command line only has python3, so buck can't detect and rebuild things if the host interpreter changes. This breaks cache consistency, including the remote cache.
• There's no check for a minimum version. The bootstrapping currently requires 3.14, or 3.12 with zstd.
• Also, overlap: tine.python_interpreter already lets a project point the toolchain at a target of its own. The new flag skips the target and falls back to PATH.
• This does not work where tine runs the bootstrapped python on the host, like for ty or PYTHON_TEST_INTERPRETER.
• Host stuff like sitecustomize and PYTHONPATH leak into the build.

This is also undocumented, and untested. It could at least have a single test that enables this option, in a new isolation dir, and builds a small target.

Addressed.

An alternative might be to pin a musl build/loader in addition to Python, and invoke it as ld-musl-x86_64.so.1 bin/python3.14. That would actually improve hermeticity compared to today.

A musl Python doesn't help here. The drivers load glibc-built libraries into the interpreter with ctypes, such as the
box's libseccomp, libkmod and libalpm, and a musl interpreter can't load those. The static musl build can't load any
library at all, and the dynamic one needs /lib/ld-musl-x86_64.so.1, so it hits the same loader-path problem. The
host's python3 already works with the host's own libc and loader.

[martinpitt]

OK, got it. Does nix-ld help?

[katexochen]

OK, got it. Does nix-ld help?

I don't want to run that. It can't be scoped to a project but is system-wide configuration with massive impact.