Support a .venv file

[brettcannon]

The file would have a single line specifying the absolute path to a virtual environment.

If it was desired to play nice with oh-my-zsh users, if WORKON_HOME is set, use that as the anchor point for any relative path specified in the file (I'm not willing to assume ~/.virtualenvs).

This originally came up from https://discuss.python.org/t/trying-to-come-up-with-a-default-directory-name-for-virtual-environments/3750 .

[brettcannon]

If this takes an absolute path then we could also support this in the Python extension for VS Code.

[brettcannon]

It also be simpler to only take an absolute path, since tooling that cares about e.g. $WORKON_HOME can take that under consideration itself and leave the Launcher out of it.

[brettcannon]

The other option, as mentioned below, is to only support relative paths based on the location of .venv. It would probably require having a restriction that if you try to go beyond the root directory that it's an error.

[uranusjr]

Pipenv implements this in a slightly different way:

1. If there’s a / in the content, it’s treated as a path
   a. If absolute, use as-is
   b. If, relative, resolve against the file’s containing directory
2. Otherwise it’s treated as relative to WORKON_HOME

This covers both the environment-in-project and virtualenvwrapper use cases, but introduces some security concerns since the / case allows activating an environment located anywhere on the file system. I think any new implementation should restrict the target to be in the directory or a subdirectory relative to WORKON_HOME or the .venv file.

[brettcannon]

If WORKON_HOME was more of a standard I would be more on board, but it's only a virtualenvwrapper thing.

As for a security concern, how is that any different than a symlink? Is it because you're worried about a malicious repo being opened and then a user of the Python Launcher being tricked into using it by executing against their system Python? I was planning to still check that the file pointed at a virtual environment, so that specific concern wouldn't exist.

But supporting a subdirectory isn't useful as this is primarily meant for those that keep their environments in a global location on their file system. You can do that right now anyway via a symlink (although you could probably do all of this via a symlink, so maybe this just isn't useful regardless).

[uranusjr]

I think it’s more of a perceived danger vs actual danger thing. When you run a symlinked command, it’s pretty obvious what you are invoking and you need to buy into that. The same danger is less obvious when you always just run py something. IIRC this was also a topic for PEP 582; a previous draft proposed looking for __pypackages__ in the current working directory, but was changed to instead look relative to the script’s location instead for similar concerns.

[brettcannon]

I think #168 will solve this.

[brettcannon]

Actually, it could solve it, but I think it might be useful to bake it in to lower the barrier for some tools to integrate with the Launcher.