PEP 832: virtual environment discovery

[brettcannon]

@ofek

I’d much prefer that this PEP not handle multiple environments at all and just have it be about .venv.

I’m willing to do that, but the way I’m interpreting what people have been saying is .python-envs has more support.

@ofek

I’ll do a PEP for the WSP approach toward the end of summer.

Notice I didn’t say I wouldn’t to a WSP PEP, just not in this PEP. I already started a discussion at Various ways of defining how to call a workflow tool for WSP to continue on in a different space.

@steve.dower

Does this imply that IDEs/(front-end tools) should look inside a path for a pyvenv.cfg (if that’s all they want to support) and ignore any that don’t have it?

Yes (which were covered by PEP 405 – Python Virtual Environments | peps.python.org). Same as conda environments have a HISTORY file (Lucas provided a link to a CEP earlier about that).

@steve.dower

And back-end tools should be generating something specific so that they can recognise their own environment from path/file-system alone?

That’s up to them if they even care. My assumption is any tool that uses .python-envs already has a specific place they put their environments, so they can tell just from the path which environments they created.