3 ms·
After some trial and error I have now settled on the following "stack": 1)I manage python versions with pyenv 2)For each new project I create a new virtualenv w
by jpalomaki 3y ago
After some trial and error I have now settled on the following "stack": 1)I manage python versions with pyenv 2)For each new project I create a new virtualenv with venv "PYENV_VERSION=3.10 python -m venv .venv" 3)Then I start jump into the venv and initiate the project with Poetry ("poetry init -n") and manage dependencies with Poetry.
If I'm keeping the projects under Dropbox, then I'll just add the .venv folder to the ignore list ("attr -s com.dropbox.ignored -V 1 .venv") to reduce the amount of files that need to be synced. If I need to get back to old project, I simply recreate the venv and install dependecies using Poetry.
A good habit would be to add a .pythonversion file on the project folder. Pyenv can pick that up and it is then obvious which version was used for the project.
I do development on Windows, but run all the Python stuff on WSL2 and use VS code for notebooks and everything. One thing I haven't looked at is using pipx to manage Poetry. Now I simply have one Poetry version installed.
Pyenv has worked fine once I managed to collect all the necessary dependencies to Ubuntu. For me it's not just to switch between Python 3.x. I like the fact that you can easily have different patch versions and match exactly the version I would use in production (via containers).
- p33p 3y agoOdd 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 3y agoPersonally 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 3y agoOne 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 3y agoNow 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 3y ago> 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!
- deleted 3y ago[deleted]