PEP 668: Ability to have relative paths instead of absolute paths

[RustoMCSpit]

Feature or enhancement

Proposal:

What's the problem this feature will solve?

So I just started using PIP and got an "externally managed enviornment" error, I suspected this was due to me changing the file location so I ran echo $PATH and found that it was looking for my file in its old location and then I did which pip and found it was resorting to my system wide pip in ./local

This is a problem for me, after doing some light searching online it appears pip uses exclusively hard coded absolute addresses and they can't be changed. That's possibly incorrect, but that's what I've read, hence the issue request.

Describe the solution you'd like

The ability to either change the PATH variables or set it to a relative one instead

Use Case

To explain my specific use case, I have files synced to a laptop and PC. The problem is VENV's break between the two because those devices obviously have to have different names, and thus they have different absolute paths.
e.g.
home/laptop/pythonProjects/venv/source/bin/activate and home/pc/pythonProjects/venv/source/bin/activate

Allowing users to make PATHs relative, so the VENV would check a user selected folder, e.g. pythonProjects, allowing for compatibility between the two as the VENV would check pythonProjects/venv/source/bin/activate on both systems would be great.

Still, the ability to be able to change PATH variables, which was extensively discussed here https://discuss.python.org/t/q-what-stops-a-venv-from-being-relocatable/57166, would be ideal if a suitable method could be found to implement this.

Better yet, have VENV be intelligent enough to determine its location has changed and attempt to update its PATH variables automatically to match its new location.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

pypa/virtualenv#2854
pypa/pip#13259

[terryjreedy]

@pfmoore Does this PIP request belong elsewhere?

[pfmoore]

It's not a pip request - the user is just confused over terminology. The best I can understand, the user is asking for the ability to have virtual environments created by the venv module be relocatable - by using relative paths, specifically. This is the correct tracker for the feature request (the virtualenv project has stated that they will not implement this unless core Python does).

I've explained on the pip tracker that virtual environments are not relocatable by design. And that having a way to make them relocatable is something that has been tried before and turned out to be impractical. And it's been explained that the venv documentation explicitly says not to move or copy virtual environments but to recreate them.

If someone did want to look into this further, some specific places where absolute paths are used:

1. The paths in the activate script. These could be made relative, I guess, but doing so would probably require careful shell-specific handling to interpret paths relative to the script location.
2. Paths in executable entry point wrappers installed by pip. This is probably the biggest showstopper, as these use absolute paths by design, so that they can be copied independently of the venv and still work. Tools like pipx rely on this behaviour, and pip will not change this - it's been asked before and we have refused (I don't have links to hand right now, I'm afraid).
3. There may well be other places which would need to be changed, these would have to be identified and fixed.

So my personal view is that this request should be rejected, basically virtual environments are not relocatable by design, and making them so would be a lot of work and extremely disruptive to the existing ecosystem, whereas the benefits are minimal. I'm not the venv maintainer, though, so if @vsajip or @FFY00 feel differently, I'll defer to them.

[RustoMCSpit]

Well there are alternative solutions:

1. Relative Paths
2. Multiple Absolute Paths
3. Allowing to change the single Absolute Path in PATH Variables to another Absolute Path manually
   3b) Having VENV automatically change its PATH Variable upon being moved would be a nice bonus feature

Benefits:

1. Being able to sync VENV across device (USB, File Syncing, whatever)
2. Being able to internally move VENVs in a system when needed

[pfmoore]

If you are genuinely interested in having this feature, and are unwilling to accept the opinions being given to you by others, I strongly suggest that you try to implement your proposal in a copy of the stdlib venv module. I am personally pretty certain that it's not possible to do what you suggest, but rather than debate it, if you can show us working code then that will be a far more compelling argument than simply stating that "there are solutions".

But honestly, I'd suggest that your time would be better spent learning how to use virtual environments the way they are intended to be used.

[RustoMCSpit]

It's a suggestion, if you want me to close this then I will. Also, respectfully, this issue request isn't materialising because I'm ignorant, it's because a feature could be improved.

[terryjreedy]

Non-trivial feature requests should be first discussed on https://discuss.python.org/c/ideas/6.

[RustoMCSpit]

Non-trivial feature requests should be first discussed on https://discuss.python.org/c/ideas/6.

That site does not open for me

[terryjreedy]

Try with discuss.python.org

[RustoMCSpit]

Endless loading screen

[vsajip]

So my personal view is that this request should be rejected, basically virtual environments are not relocatable by design, and making them so would be a lot of work and extremely disruptive to the existing ecosystem, whereas the benefits are minimal

I completely agree.

[pfmoore]

Endless loading screen

It probably doesn’t matter. You’ve had responses from multiple core devs now, including one of the maintainers of venv, saying that we shouldn’t do this. I would advise you to simply drop the idea.

[RustoMCSpit]

'''Use Case
To explain my specific use case, I have files synced to a laptop and PC. The problem is VENV's break between the two because those devices obviously have to have different names, and thus they have different absolute paths.
e.g.
home/laptop/pythonProjects/venv/source/bin/activate and home/pc/pythonProjects/venv/source/bin/activate
'''

Off topic.

What alternative would you advise for my use case as venv can't realistically be made suitable? Docker / Podman? Something else?

[pfmoore]

Don't sync the venvs, recreate them on demand. You should have a requirements file that says what's to go into the venv, so python -m venv .venv; .venv/bin/pip install -r requirements.txt is all you need. If you really can't maintain a requirements file, pip freeze can create one for you (again, on demand).

[RustoMCSpit]

So should I have a file structure that has all the venvs under one big venv folder and i connect to them as needed, and then sync the programs and their files somewhere else?

[pfmoore]

Honestly, at this point, designing your workflow is up to you. Normally I advise against having venvs located outside the project structure, though. Can't your sync process be told to exclude certain subdirectories?

For this sort of advice you should post on the Help category in the Python Discourse, though. This is not the appropriate place for such advice (and the people on Discourse are more likely to be able to help, as well).