Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyenv – lets you easily switch between multiple versions of Python

github.com

Post reply on HN
Print view View original

31–40 of 341 posts

Re: Pyenv – lets you easily switch between multiple versions of Python

#31

Post by rcarmo »

TomSwirly wrote: post #24

This is a truly, truly terrible idea. It adds several failure modes, some subtle so you can go a long way in a state of error, just so beginners can type `python` instead of e.g. `python3.10`. Many developers, not just me, have a similar setup: we use virtual environments everywhere, and if you aren't in one, `python` doesn't even resolve to a symbol. If I want to write a quick script with no dependencies, I directly…

This is not a terrible idea. It is a tool that makes it possible for people to either retrofit a newer version of Python onto an ageing OS or to develop for a specific older version of Python on a newer OS. If you don't need the features the tool uses, you shouldn't use it--I don't see why you're comparing it to virtualenvs, it provides completely different runtimes with a different engine and a standard library, and the ability to switch between those by just cd'ing to a folder with a .python-version file in them.

Re: Pyenv – lets you easily switch between multiple versions of Python

#32

Post by formerly_proven »

kzrdude wrote: post #23
bmitc wrote: post #12

Earlier quoted context omitted.

> it compiles python on your machine What is the alternative? Every solution that I know of on Linux requires you to build Python on the machine: asdf, official Python downloads, etc.

These builds are an alternative: https://github.com/indygreg/python-build-standalone Those are what Rye and hatch use. Drawbacks: late availability of patch versions, various quirks from how they are built (missing readline, missing some build info that self-compiled C python modules might need.)

I think PEP711 (https://peps.python.org/pep-0711/) is (eventually) a better alternative, because it builds on top of the proven manylinux approach to binary compatibility.

Re: Pyenv – lets you easily switch between multiple versions of Python

#33

Post by rcarmo »

Hamuko wrote: post #29
lgxz wrote: post #27

I think the only problem of pyenv is that you can't upgrade an old virtualenv to a newer Python version.

Isn't that more of a limitation with virtualenv? I've been using virtualfish as my venv manager in the fish shell and it has a `vf upgrade` command for upgrading virtualenvs to newer versions, either by updating in-place or rebuilding the entire virtualenv. So far has worked nicely with my pyenv Python installs.

Yeah. I had a shell snippet someplace that was essentially pip freeze | remove virtualenv | make virtualenv | pip install. It's not that hard.

Re: Pyenv – lets you easily switch between multiple versions of Python

#34

Post by happymellon »

TomSwirly wrote: post #24

This is a truly, truly terrible idea. It adds several failure modes, some subtle so you can go a long way in a state of error, just so beginners can type `python` instead of e.g. `python3.10`. Many developers, not just me, have a similar setup: we use virtual environments everywhere, and if you aren't in one, `python` doesn't even resolve to a symbol. If I want to write a quick script with no dependencies, I directly…

Isn't this a completely different concept?

Virtual environments are for your installed dependencies, whilst pyenv is for installing python.

I have a client that uses Python X and another that strictly uses Python X+1.

The virtual environments are so that I can have the project dependencies installed and the pyenv lets different companies have different cadence for their Python upgrades.

I could be completely mistaken and mixing up my Python support utils as I've not had a client request Python for a couple of years.

Re: Pyenv – lets you easily switch between multiple versions of Python

#36

Post by dallyo »

blowski wrote: post #3

OP - I'm curious why you've submitted this today, you seem experienced enough to guess this is not the first time you've used it. Has there been a major change or something happened in the community I need to know about? Or are you just spreading the love for a great piece of open source software?

Also a bit confused as to why this is currently the #1 post.

Re: Pyenv – lets you easily switch between multiple versions of Python

#38

Post by jpalomaki »

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).

Re: Pyenv – lets you easily switch between multiple versions of Python

#40

Post by nlitened »

Tools you can use to make sure the Python program you wrote keeps working: requirements.txt, pip, pipenv, pyenv, virtualenv, pyenv-virtualenv, virtualenvwrapper, pyenv-virtualenvwrapper, venv, pyvenv, conda, miniconda, poetry, docker, nix.

Which ones did I miss? Which of them actually ensure your program always works the same as when you first wrote it, without asterisks?

Post reply on HN