Open ofek opened 5 months ago
This definitely should not be the default. Entry point wrappers are built with absolute paths to the interpreter so that the wrapper can be copied or symlinked to other locations, without needing to copy the Python environment as well. This is something that's used by a lot of applications - most notably pipx
, which symlinks ~/.local/bin/appname.exe
to ~/.local/pipx/venvs/appenv/Scripts/appname.exe
.
Makes sense, thanks for that context @pfmoore.
I have a similar use-case. It would be great to be able to skip patching wrappers post-install.
(On Windows-systems I am using <launcher_dir>
for distlib-based launchers)
FYI since https://github.com/astral-sh/uv/pull/3717 this is now completely possible to implement and I do so here:
I'm confused as to what's happening here. I could test, but I have limited time right now so if someone can explain, I'd be grateful. If I uv pip install
a project that has a script entry point, does that entry point by default still use an absolute path to the Python executable binary?
Yeah. We didn’t change any behavior in uv itself, except we changed our Windows trampoline to accept a relative path (though we never write one to it in uv). Ofek is then post-processing the scripts in Hatch, I think, to rewrite the absolute paths as relative.
Yes that is exactly correct and I can remove that entire logic once such a flag exists in UV! I posted those links mostly to assist in someone doing the implementation.
I have a use case where I need to pre-build an entire installation which will be distributed to any number of machines. When installing packages that have entry points, the location becomes hardcoded to an absolute path.
Instead, this should be relative to the Python executable used for installation. For non-Windows systems the python-build-standalone project does this for pip for example:
The trampoline logic should be equivalently simple for Windows.
Maybe this should become the default in future?