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.
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.
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.
Python really makes things difficult :D
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!