Hey @paultiplady,

I'm not sure I can follow you. Maybe you misunderstand what virtualenvs.prefer-active-python is doing? It's saying: "If Poetry creates a venv it should pick up the current activated python interpreter to create this venv".

So can you please point out what you've expected to see and what happens instead? This makes it easier to understand whether there is an issue or not.

fin swimmer

Thanks, it looks like I misunderstood what's going on with this flag then. I read #4852 and perhaps didn't read too much into "the pyenv way", assuming that meant how I was familiar with folks using Pyenv.

The workflow that I used with Poetry from when it first came out until when it broke some time in the last year was to use pyenv with the pyenv-virtualenv plugin to manage the venv. (The pyenv incantations I shared at the top of my original post). This means when I cd into the project directory, my venv is automatically activated, and I don't need to say poetry run <python-entrypoint> or poetry shell to use in the venv, I just have my venv activated automatically. (I'd previously just install poetry inside the per-project venv, and that worked fine up until some point between 2022 and now.)

In my Dockerfiles I was using virtualenvs.create=False but I don't think I was explicitly setting that in the dev env config. (I do have that flag set now on my new "official installer" install.)

It feels like the code that currently exists is pretty close to working as I expect it with virtualenvs.prefer-active-python=True & virtualenvs.create=False, and regardless of whether that's intended to be supported, I suspect there is still a bug; with prefer-active-python=True shouldn't poetry env info show the currently-active python (in this case a virtualenv), not the system python that was used to install poetry?

To be clear, in the diags I provided above, this command:

> poetry env info -vvv
Loading configuration file /Users/paul/Library/Application Support/pypoetry/config.toml

Virtualenv
Python:         3.10.10
Implementation: CPython
Path:           NA
Executable:     NA

System
Platform:   darwin
OS:         posix
Python:     3.10.10
Path:       /Users/paul/.pyenv/versions/3.10.10
Executable: /Users/paul/.pyenv/versions/3.10.10/bin/python3.10

Is being run inside the venv /Users/paul/.pyenv/versions/pet/bin/python. I want poetry to use the active python (in this case a venv), not infer the system python.

For what it's worth, I retested this using a non-venv pyenv version and the instructions in https://python-poetry.org/docs/managing-environments/, and that's broken in the same way; I think that is the expected usecase from the docs:

❯ pyenv local 3.9.9

❯ poetry env info

Virtualenv
Python:         3.10.10
Implementation: CPython
Path:           NA
Executable:     NA

System
Platform:   darwin
OS:         posix
Python:     3.10.10
Path:       /Users/paul/.pyenv/versions/3.10.10
Executable: /Users/paul/.pyenv/versions/3.10.10/bin/python3.10

In this case we should be pulling the 3.9 pyenv version as the active python version, and instead it's pulling 3.10.10 (the pyenv system version, used to install poetry).

My fix resolves this case too (though I see now that we can't hardcode the executable to a VirtualEnv, since it might be a non-venv interpreter. Maybe it can be a GenericEnv?)

I also misunderstood how virtualenvs.prefer-active-python = true should work. however I just wasn't able to use pyenv & poetry together: I had the same problem that poetry install would create a new venv, even though I had virtualenvs.prefer-active-python = true and my pyenv venv was active.

with virtualenvs.create = false it would install everything into the system python (a pyenv version in my case). using @paultiplady's fix it works for me