Setting up some guidelines around discovering/finding/naming virtual environments

[brettcannon]

@ofek

Before I vote, we are kind of hand-waving away support for multiple environments at this stage, right?

I am because no one really latched on to that idea.

@aragilar

How would having a .venv file/directory interact with an already “activated environment” (assuming we can agree on what that means)?

@uranusjr

Assuming I interpret Brett’s intention correctly, nothing.

Correct, or more to the point it’s up to tooling to decide.

@steve.dower

If it’s not going to go into VCS, then it’s got no reason to be portable between tools. It’s a per-user setting at that point. Users who regularly switch between editors are the special breed.

I don’t view this as a “switching” issue, more of an “integration between tools” issue.

@steve.dower

Having a file point to a shell script (which shell[s]?) that modifies the environment (which process?) so that a PATH search will find a symlink/copy/redirector to a Python runtime is a very convoluted solution.

Who said anything about pointing at shell scripts when it came to the .venv file idea? And virtual environment don’t require PATH manipulation to work, so I don’t see what that has to do with this either.

@steve.dower

For reference, when I was maintaining an editor our approach was “provide the path to Python and we’ll run that, or if you want us to create an environment we’ll use venv”.

And that’s what we already do in VS Code. But people also want support for their package management tooling which has already decided where things like a virtual environment are going to be. And this tooling can be by preference or by edict from their team. And people don’t love having to specify something that is already known somewhere else. And I hate having to write custom code for every package management tool just to find something they already created.

@steve.dower

If we were to go anywhere here, I’d suggest we do a PEP 517 but for environment creation and package installation

A potential issue with this is the boilerplate that projects would have people copy over to their pyproject.toml. The .venv solution at least leaves it with the tools already doing the work that users installed and are using.

@rgommers

@steve.dower

All I want to present is that the original proposal is at best not very useful, and at worst limits our ability to make improvements in the future, and those potential improvements exist but aren’t agreed upon yet.

That I agree with.

What “potential improvements” are you thinking of here that we have not agreed to yet? Is this a reference to the other discussions going on about a unified packaging tool?

As for the usefulness, I personally have a use case today that has existed for years and persists being a problem. If virtualenvwrapper and/or pyenv-virtualenv adopted the .venv file proposal it would be a big win. Add on tools like Poetry, Hatch, and PDM, then suddenly their workflows participate with tools. (I’m not worrying about conda as people can specify conda environment names in an environment.yml file).