PEP 832: virtual environment discovery

[brettcannon]

@kramkowski

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?

It should and I will clarify that.

@kramkowski

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.

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).

@kramkowski

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.

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).

@kramkowski

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 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:

1. Keep the PEP as-is, have it ignored by uv and Hatch, and hope other tools adopt it
2. Go back to a .venv redirect file, hope people use it, and say sorry to conda
3. Drop the PEP and hope WSP gets a better reception

So obviously no “make all the people happy” option.