[p33p]

Odd to me that you don’t let poetry create the venv? Why do this separately?

Our flow is similar: pyenv (windows and linux), pipx, poetry.

We’ve also defaulted poetry to utilize the current global version of Python and build the venv within the project folder.

[lexicality]

Personally I've had problems with poetry managing virtualenvs in the past so I just don't let it touch them any more. Maybe it's better now, but I don't see any reason to risk it, given how often Python seems to like to ruin my day. I also don't like that by default it wants you to use `poetry run` to run things. Sure you can configure it not to, but it still annoys me

[Hackbraten]

One issue I’ve been encountering is that Poetry isn’t aware of pyenv or `.python-version`. So what I do to initially build my venv is:

    pyenv exec pip install poetry && pyenv exec poetry install

This creates the venv against the correct Python version, and I can now do without `pyenv exec` for this repository.

And every time that `.python-version` changes (which I at most do a few times per year per project,) I throw away the `.venv`, do `pyenv install -s` and start over.

Your `poetry run` point still stands, though.

[0x008]

Now you have poetry installed for every version of python and need to keep track of updating all of those poetry installs.

Python really makes things difficult :D

[Hackbraten]

> Now you […] need to keep track of updating all of those poetry installs.

You’re absolutely right.

On second thought, I guess I only need these Poetry installs just once anyway: for creating the venv and then never again. That’s not worth it.

So here’s a new method that does away with these extra Poetry installs:

    pyenv exec python -m venv .venv && poetry install

assuming that a `poetry.toml` exists with `virtualenvs.in-project` set to `true`.

Going to adopt this variant from now on, I guess. Thank you for your thoughts!