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

71–80 of 341 posts

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

#71

Post by renegat0x0 »

infecto wrote: post #65
nlitened wrote: post #40

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?

I am always curious how many people, outside of those building code for third party clients, actually hit this problem? In the 10+ years of using Python I have never had a problem using the core tools. The ecosystem is far from perfect but it has never cause me a problem. Edit: Wow y'all are some sour people for voting down this question. I truly wonder how often people run into this problem compared to just complain…

I am not sure about what 'core' means in this context.

In my edperience I had many many problems with OS packages vs pip installed ones. There were really strange dependency issues.

In some cases I encountered dependency hell.

Even if somebody said to me that the core means also using virtualized en I would disagree as places over Internet not always explicitly guide you in that route.

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

#72

Post by codethief »

nlitened wrote: post #40

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?

asdf can be used as an alternative to pyenv. (In fact, it is not only meant for the Python ecosystem, so it can also replace nvm and others.)

For me, the combination of asdf and Poetry has worked quite well recently: I use asdf to pin the Python & Poetry version and then use Poetry to pin everything else.

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

#73

Post by lioeters »

ktosobcy wrote: post #37

Python (and Ruby) handling of versions and dependencies is truly awful... :-(

I've only used Python occasionally, and more than half of that time I ran into issues with the installed Python version or dependencies. Not only version 2 vs 3, but for example a certain project required exactly 3.11, not 3.10 or 3.12. Last time, I tried to install Caddy and broke all previously installed packages/commands - and after searching for a solution and trying different things, the best I could come up with was to switch versions (manually) before and after running a command to restore the environment.

Now I understand I should have been using Pyenv the whole time. But it sure felt unfriendly for a newcomer to the language/ecosystem. Granted my learning approach is to jump in without much preparation, I wish the language designers or the ecosystem provided a better experience when things don't work right.

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

#74

Post by adolph »

scaryclam wrote: post #70
latexr wrote: post #56

Earlier quoted context omitted.

> Ensures you have the same python environment. But not the same Python runtime, which does not fulfil the request of guaranteeing it works the same later without asterisks.

I'm not sure what you might mean by runtime, but a python venv does make sure you're using the same runtime. There are symlinks in the environments bin directory to the specific runtime. If you're plonking a python3.12 binary over the top of the python3.11 one, then yeah, you'll be using a different one, but that'd be an issue nomatter what you're using. Just don't uninstall your python binaries and you're fine. If y…

If you attempt to reproduce a project in a repo that only includes source and requirements.txt you will not have metadata about the version of Python used.

It seems that there is a way to do this in pip but I don’t think it is widely used: https://stackoverflow.com/questions/19559247/requirements-tx...

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

#75

Post by yxhuvud »

ktosobcy wrote: post #37

Python (and Ruby) handling of versions and dependencies is truly awful... :-(

How is it awful on the Ruby side? In my experience it is a solved problem since bundler was invented 15 years ago. It's been very free from pain during the last 10 years or so.

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

#76

Post by aequitas »

nlitened wrote: post #40

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?

You're missing Tox[0] & Nox[1]. Tox is actually quite nice when dealing with testing code across different versions of Python.

[0] https://tox.wiki [1] https://nox.thea.codes/en/stable/

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

#77

Post by punnerud »

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?

I used Python a lot, but missed pyenv. Used it for some weeks now and was thinking this is something I would like to know about earlier (thats normally when I post it to HN).

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

#78

Post by latexr »

scaryclam wrote: post #70
latexr wrote: post #56

Earlier quoted context omitted.

> Ensures you have the same python environment. But not the same Python runtime, which does not fulfil the request of guaranteeing it works the same later without asterisks.

I'm not sure what you might mean by runtime, but a python venv does make sure you're using the same runtime. There are symlinks in the environments bin directory to the specific runtime. If you're plonking a python3.12 binary over the top of the python3.11 one, then yeah, you'll be using a different one, but that'd be an issue nomatter what you're using. Just don't uninstall your python binaries and you're fine. If y…

> but a python venv does make sure you're using the same runtime.

It does not.

> There are symlinks in the environments bin directory to the specific runtime.

Precisely. They symlink to a path. Which means that if you have a certain version of Python at one location (let’s say /usr/bin/python3) and later update that (let’s say by upgrading macOS and the Xcode developer tools), the same virtual environment will point to a different version of Python.

> Just don't uninstall your python binaries and you're fine.

That’s not a practical solution. Sometimes you don’t have a choice, as demonstrated above. By that logic one could say “don’t change anything about your system and you don’t even need virtual environments”. Which is somewhat true, but also profoundly unhelpful.

The point of the question was to reproduce the same thing without asterisks and you’ve introduced a major one and called it a day.

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

#79

Post by jscheel »

ktosobcy wrote: post #37

Python (and Ruby) handling of versions and dependencies is truly awful... :-(

In my experience, python has been far, far worse than ruby. Now, to be fair, I’m much more comfortable in the ruby ecosystem, but still, everything feels much more brittle in python package management.
Post reply on HN