feat: auto_venv support for in-project venvs, created with pyenv

[b0lle]

I had some trouble activating venvs which are defined in-project (e.g. /Users/User/project/.venv) and realized that this is not supported. The virtual environment has to be created with pyenv, so that the plugin can parse the venv-name out of the pyvenv.cfg file (promt variable).

home = /Users/hi-there/.pyenv/versions/3.10.11/bin
implementation = CPython
version_info = 3.10.11.final.0
virtualenv = 20.26.0
include-system-site-packages = false
base-prefix = /Users/hi-there/.pyenv/versions/3.10.11
base-exec-prefix = /Users/hi-there/.pyenv/versions/3.10.11
base-executable = /Users/hi-there/.pyenv/versions/3.10.11/bin/python3.10
prompt = my-package-py3.10

If a venv was found in-project, it takes precedence over venvs defined in the "centralized" venvs folder in user directory.

Let me know what you think about the additions. If thats something interesting for anybody I could look for a solution for venvs which were not created with pyenv.

[b0lle]

Hey, thanks for reviewing :). You are right. I think you can even configure virtualenv to create the venvs in project. In poetry you also have the in-project option to define where the venv should live.

I personally prefer the in-project option for several reasons:

• it's easy to have a look at installed dependencies
• it's easy to remove
• when working with git worktrees, it's clearly defined which venv belongs to which project.
• edit: the venv will be deleted when one deletes the worktree 😍

I had tested the code within my setup and it works pretty well. But I didn't had the chance to test it with a common dir, like yours. Can you try it, after I fixed the code which regards to your comment?

[AckslD]

That makes sense! I tried the version in my own setup and seems to work from what I can tell :+1:

[b0lle]

I finished my additions :)

[AckslD]

Thanks for the nice contribution!