-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
Support for relative home path in pyvenv.cfg #83650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Currently, the interpreter only supports absolute paths for the 'home' directory in the pyvenv.cfg file. While this works when the interpreter is always installed at a fixed location, it impacts the portability of virtual environments and can make it notably more-difficult if multiple virtual environments are shipped with a shared interpreter and are intended to be portable and working in any directory. Many of these issues can be solved for if 'home' can use a directory relative to the directory of the pyvenv.cfg file. This is detected by the presence of a starting '.' in the value. A common use-case for this is that a script-based tool (e.g. black or supervisor) may be shipped with a larger portable application where they are intended to share the same interpreter (to save on deployment size), but may have conflicting dependencies. Since the application only depends on the executable scripts, those packages could be packaged into their own virtual environments with their dependencies. |
Do note that virtual environments are not designed to be portable in general, so this would be a fundamental change in the design and purpose of virtual environments. |
I would say they’re not designed to be, but the also aren’t designed to not Suffice to say, is there a significant reason to not allow it? On Tue, Jan 28, 2020 at 10:28 AM Brett Cannon <[email protected]>
|
We have to support that use-case forever. ;) In all seriousness, relative paths get tricky when you forget to resolve the path as appropriate (and in a way that people expect) and it requires making sure that this will work for the next 30 years, so it's not a small thing to take on. |
It's poorly supported by packaging. In particular, relocating an environment isn't supported with entry-point scripts, which pip installs with a fully-qualified shebang. Moreover, entry-point scripts in Windows are created as exe files (e.g. "pip.exe") that embed the fully-qualified path of python[w].exe in the environment, plus a zipped __main__.py. For example, given an environment at "C:\Temp\env", running "C:\Temp\env\Scripts\pip.exe" in turn spawns a child process with the command line: "C:\Temp\env\Scripts\python.exe" "C:\Temp\env\Scripts\pip.exe". This breaks if the environment is renamed or relocated. |
Interesting, I hadn’t realized that it would embed the FQ Executable path, I’ll think about it a bit more On Tue, Jan 28, 2020 at 2:33 PM Eryk Sun <[email protected]> wrote:
|
While portable venvs aren't general purpose venvs, they do work if you purge the For that case (where the directly executable files are deleted outright rather than attempting to fix them up), That said, it's useful to run a postinstall script after relocation in order to recompile the Python source files on the target system anyway, and it's reasonably straightforward to have that file generate a suitable from pathlib import Path
runtime_executable_path = Path(sys.executable).resolve()
runtime_version = ".".join(sys.version_info[:3]
venv_config = f"""\
home = {runtime_executable_path.parent}
include-system-site-packages = false
version = {runtime_version}
executable = {runtime_executable_path}
"""
Path(__file__).with_name("pyvenv.cfg").write_text(venv_config, , encoding="utf-8") |
FWIW, this is a deal breaker for us when generating these venv using Bazel, as it prevents cache sharing of these files with other people. Relative paths are not new, and is well understood by most engineers already, and since venv is already an advanced concept, i don't see why this restriction can not be lifted. |
It's not clear what you mean when you say "only allowing is a deal breaker for us". Only allowing what? Sorry if I'm being dense. |
sorry a typo. i meant this is a deal breaker for us. |
There is no issue in changing For now, when |
I didn’t know this was even permitted. So relative path is permitted but resolved to the current pwd? |
Yes, and you will fail to start python if you are not running it in the same directory as |
The project where I needed this has been published as open source since I commented on this issue, so the relevant post-install script is now available for direct linking: https://github.com/lmstudio-ai/venvstacks/blob/036d4e2629424fcd24e11cdec7d02110e39f6666/src/venvstacks/_injected/postinstall.py#L55 The interesting part of that function for purposes of this discussion is the
So even if relative path support is added (with the meaning of "relative to the venv config file"), there's an open question around whether it should resolve symlinks or not when making the relative path absolute. It possibly shouldn't (for the same reasons That said, the issue is still open because we think it's a reasonable thing to add, it's just that none of the current maintainers have a sufficient motivation to work on it (my looking into it for |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: