I’ve also asked in Brett Cannon: "Curious what people think about https://peps.pyth…" - Mastodon to see if the community has a clear opinion (probably not, but you never know).
1 Like
That is one option, yes. Designing this properly seems non-trivial, though. I don’t really want to cause too much work here.
While codifying .venv redirect files would be the ideal outcome, failing that, could they be mentioned as deferred? That would leave the option more clearly open without expanding this PEP’s scope.
Certainly. But I will also say that just because a PEP rejects an idea does not preclude it being brought up again in the future.
We wanted to ask for some clarification on this part of the PEP:
The last environment listed in a .python-envs file MUST be considered the default environment when a default environment is desired. IF a tool does not support the last environment listed THEN the tool MUST either ask the user which environment to use OR error out.
For uv’s project commands (add, sync, run, etc…), we would want to continue using or creating .venv without consulting .python-envs. Would the PEP allow this even when .python-envs exists and .venv does not?
Regarding this bit:
IF a tool can detect that an environment is already in use (e.g. the VIRTUAL_ENV environment variable is set), THEN tools SHOULD respect the user’s choice and use the activated/in-use environment over the default environment when no previous environment selection has occurred. Tools MAY choose to override even a previous environment selection if an environment is detected as activated/in use.
Just as a data point: Currently we warn for project commands when VIRTUAL_ENV is set and doesn’t match what we would normally use, and require passing --active to opt into using it. So we don’t currently follow this recommendation, and would not change this because doing so would go against our users’ expectations.
Lastly, we don’t think the PEP sufficiently justifies including .python-envs. We have already said that uv won’t write to it, and @ofek (Hatch) has also argued against including .python-envs as a substitute for WSP. So far tox and virtualenv are the only environment-creating tools listed in this PEP as supporting it, with draft PRs for writing to this file.
We understand that projects can have multiple environments, but improving automatic discovery depends on the tools that create those environments writing to this file. We think this PEP should go further to explain the expected adoption and why that would provide enough benefit to consumers to justify standardising the mechanism.
I am not going to block progress on this PEP because I see the value for other tools having it this way. But for hatch it is not likely the path we want to take to provide programmatic discovery of our multi-environment approach. It is more likely that Ofek and I, if Brett does not see value in a PEP for WSP, will take the WSP approach.
It should and I will clarify that.
Totally fair and why it’s a “SHOULD”; you can choose not to do that, but you should have a good reason to (which you do).
There also haven’t been many “no” responses either. I haven’t heard one way or another from:
- Nox (@henryiii )
- PDM (@frostming )
- Poetry (but @radoering is already prototyping)
- Pixi (@lucascolley , although they suggested support earlier)
- Conda (@jezdez )
- PyCharm (@judy2k )
So you’re right the PEP doesn’t have a deep “yes” list, but the confirmed “no” list is so far uv and probably Hatch (although I don’t think @cjames23 has officially said “no” yet to the latest version).
I can’t predict the future nor can I force people to respond here, especially when the discussion has gone on for as long as it has. So my plan is VS Code will have support for this PEP and that’s as far as I can promise as I can’t make anyone do anything.
I want to be very clear here about the predicament I have been put in with this PEP. I don’t think anyone disputes their is a tool integration problem where finding where a workflow tool puts the virtual environment they want tools work with is a per-tool integration headache. And I have the issues on the Python extensions for VS Code to show it’s not a small user pain point when they can’t get auto-complete because VS Code can’t find their virtual environment because its some place we don’t know about.
Hence this PEP. And the version I had before .python-envs which had the .venv redirect file was very tool-positive except for a lukewarm/meh from uv and a no from Hatch (I know @cjames23 initially said “yes”, but they changed their mind later). But then bringing it here to the rest of the community led to a massive outpouring of:
- What about all of my other virtual environments?
- What about conda?
This along with Hatch’s “no” led to the whole WSP discussion which is a much bigger thing and something that didn’t have universal support either. But at least the .python-envs idea seemingly got some conda community support and people in general happy.
But now we have uv pushing back hard on .python-envs and seemingly switching from a lukewarm to a “yes” on .venv redirect files (or maybe you’re still lukewarm?).
So it seems my options are:
- Keep the PEP as-is, have it ignored by uv and Hatch, and hope other tools adopt it
- Go back to a
.venvredirect file, hope people use it, and say sorry to conda - Drop the PEP and hope WSP gets a better reception
So obviously no “make all the people happy” option.
2 Likes
And a poll to go with my “damned if you, damned if you don’t” list of options. You can assume any option includes, “and do a WSP PEP later”.
- Keep the PEP as-is, have it ignored by uv and Hatch, and hope other tools adopt it
- Go back to a .venv redirect file and drop .python-envs, hope people use it, and say sorry to conda folks
- Somehow make .venv redirect files also work with .python-env files
- Withdraw the whole PEP and hope WSP gets a better reception
0
voters
1 Like
PDM currently uses .pdm-python to point to the in-use interpreter/environment, while also treating .venv as the default environment location following community convention.
We have a draft PR (pdm-project/pdm#3834) implementing PEP 832 support. PDM is willing to support this PEP if the community can reach a reasonable consensus — we don’t have a strong objection to .python-envs, and we’re happy to write to it alongside our existing .pdm-python mechanism.
That said, I share the concern that adoption depends heavily on whether the major tools (especially consumers) are on board. A standard that’s ignored by the most widely-used tool in the space will struggle to gain traction. If the direction shifts back to .venv redirect files, PDM can adapt to that as well.
2 Likes
Redirect file in this case means a regular file with a single entry which is a relative/absolute path, right? That’s how I interpret this option.
Correct; going back to what the PEP had before the .python-envs change.
Thanks to everyone who voted! The direct vote outcome is to go back to a .venv redirect file. But there’s a different outcome if you look at votes by tools. You could argue there are:
- uv (Tomasz)
- VS Code (me)
- Pixi (Lucas)
- Hatch (Cary)
- msbuild (Steve)
That vote seems to come out with withdrawing the PEP on top. If you take Steve and me out (due to bias and tool audience, respectively), you also get the PEP withdrawal winning.
That tells me my options are:
- Go back to including a .venv redirect file and have whomever is going to have to approve this PEP decide if it’s worth it as a simple way to support virtual environments today and have WSP the way to support the whole ecosystem in the future
- Withdraw the PEP because .venv redirect files are too much of a stopgap measure if we’re serious about WSP
So it feels like a “practicality beats purity”/“now is better than never” versus " never is often better than right now" situation to couch it in PEP 20 terms.
I think the deciding factor for me will be whether my team decides it’s worth moving forward with a .venv redirect file for VS Code. If they do then I might as well give the PEP a shot and at worst it acts as documentation for how VS Code operates in the face of a .venv file. But if my team doesn’t think it’s worth it then I will withdraw the PEP and solely focus on WSP (although I still want to see WSP tackled regardless of which way I go; you can see my rough notes on WSP to know I’m somewhat serious about it).
5 Likes
Obviously I don’t disagree with the result, but I’m absolutely looking at this from my “what if I were still in charge of an IDE” perspective and not “I have a build backend” perspective. Maybe that’s still too much bias, but I don’t think it’s worth taking me out over it 
1 Like
Chiming in as an unaffiliated python developer the current wording of the PEP, if adopted by IDEs, would be great to have.
The driving issue (opening my IDE and most of my imports not being resolved due to no/the wrong environment) is a regular one, and leads to me having to explicitly activate my environments before opening my editor from the terminal. Having the correct environment activating automatically would be well worth the cost of having to add .python-envs to my project’s .gitignore.
I am however primarily a conda user; thus I would only be interesting in this if such environments were supported, which does not seem likely if .venv is the only supported file/directory. I am also one of those people who doesn’t keep environments with project code, due to my $HOME being on a slow NFS filesystem.
To provide a data point for potential breakage of making .venv a file, I actually have a small shell function in my ~/.bashrc that activates an existing virtual environment or creates a new one if not found; this function would be broken by .venv being a file. I can fix it if standardised, but others may have similar utilities.
I have a couple technical questions when it comes to parsing a .python-envs file:
- How are blank lines handled? Are they just ignored? What about if the last line is blank (e.g. double blank line at the end of the file)?
- How are paths interpreted, or is this just left to the consuming tool? I’m thinking around things like
~expansion, converting between\and/, etc.
Forgive me if I have missed something, but is this case not already covered by .venv being used as the default environment if it exists? As the PEP is currently written if uv was to create a .venv directory then it would be used, with the .python-envs only providing additional options if present. Or does uv already put environment paths in a .venv file and wants to keep its existing behaviour?
I was seeking clarity on whether uv could create .venv without first consulting .python-envs when .venv does not yet exist. Brett has since confirmed that this should be allowed and agreed to clarify the wording.
uv run normally creates .venv if needed and keeps it in sync with the project. My concern was that the quoted wording could require us to consult .python-envs first, then prompt or error if we did not support the selected default environment, rather than simply create .venv (which is what we would currently do).
1 Like
Correct, .venv would be virtual environment-only as the name would be too confusing if it was something like a conda environment.
Yes, that sort of thing is what’s expected to break if a tool used a redirect file, but the assumption if a tool that does use a .venv redirect file was already keeping a virtual environment somewhere else, so your script wouldn’t have been doing anything to begin with in that instance.
While I appreciate the interest, PEP 832: virtual environment discovery - #173 by brettcannon means I will either only do .venv files or I’m withdrawing the PEP, hence I will not be pursuing a .python-envs file approach. I do still hope to attempt a WSP solution, though, which would allow for conda environments to participate.
2 Likes