4 ms·

They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-

by plonk 3y ago

They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-codes a full path. Since venvs on Linux symlink to the system’s Python executable, they should also work after moving.

ShamelessC 3y ago
> it’s only the “activate” script that hard-codes a full path. So…they aren’t then.
- plonk 3y ago
  They are in the sense that anything one would want to do with a venv, they can do with trivial effort. You don't need the activate script, you can just set PATH, PYTHONHOME and/or PYTHONPATH and be done with it.
dragonwriter 3y ago
> They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-codes a full path. So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update. > Since venvs on Linux symlink to the system’s Python executable Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.
- plonk 3y ago
  > So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update. I don't think the maintainers have gotten a request to do that. Personally I use a more complicated launcher because I need to set things like environment variables in my deployments, but a venv is almost an out-of-the-box relocatable Python environment. It's when you need to protect/compile your code that things get messy. >> Since venvs on Linux symlink to the system’s Python executable >Hopefully, the executable with which they were created, not the system executable except where they happen to be the same. When you call /usr/bin/pythonx.y -m venv ./myenv, ./myenv/bin/python will link to /usr/bin/pythonx.y. Since there aren't many reasons to use a Python version not installed by the package manager, I call these the "system's Python executables", but sure, it can also point to /opt if you installed Python there.

by plonk 3y ago

ShamelessC 3y ago

> it’s only the “activate” script that hard-codes a full path. So…they aren’t then.

plonk 3y ago
They are in the sense that anything one would want to do with a venv, they can do with trivial effort. You don't need the activate script, you can just set PATH, PYTHONHOME and/or PYTHONPATH and be done with it.

dragonwriter 3y ago

> They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-codes a full path. So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update. > Since venvs on Linux symlink to the system’s Python executable Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.

plonk 3y ago
> So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update. I don't think the maintainers have gotten a request to do that. Personally I use a more complicated launcher because I need to set things like environment variables in my deployments, but a venv is almost an out-of-the-box relocatable Python environment. It's when you need to protect/compile your code that things get messy. >> Since venvs on Linux symlink to the system’s Python executable >Hopefully, the executable with which they were created, not the system executable except where they happen to be the same. When you call /usr/bin/pythonx.y -m venv ./myenv, ./myenv/bin/python will link to /usr/bin/pythonx.y. Since there aren't many reasons to use a Python version not installed by the package manager, I call these the "system's Python executables", but sure, it can also point to /opt if you installed Python there.