Live data from Hacker News

Pyenv – lets you easily switch between multiple versions of Python

github.com

61–70 of 341 posts

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

#61
post #53
post #46

Earlier quoted context omitted.

python -m venv myenv . myenv/bin/activate Ensures you have the same python environment. The other part is OS state.

>The other part is OS state And that's the whole problem. "The same Python environment" doesn't mean much because it underspecifies the full runtime dependency chain.

It's inherit problem for all languages based on some runtime. Java, PHP, Ruby, whatever have the same issue. And TBH it's not very major issue to start with.

No other solution besides fixed OS (containers, nix) could solve this problem.

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

#62
post #36
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.

Because it's not a solved problem, pyenv is niche and people discover it once again and think that they finally solved their pain.

They will try it, and most of them will pay the price for it.

It's a cycle.

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

#63
post #61
post #53

Earlier quoted context omitted.

>The other part is OS state And that's the whole problem. "The same Python environment" doesn't mean much because it underspecifies the full runtime dependency chain.

It's inherit problem for all languages based on some runtime. Java, PHP, Ruby, whatever have the same issue. And TBH it's not very major issue to start with. No other solution besides fixed OS (containers, nix) could solve this problem.

>No other solution besides fixed OS (containers, nix) could solve this problem.

You don't have to use NixOS to use Nix. You can install it on any Linux distro, or MacOS, and use it as your build system.

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

#64

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…

[deleted]

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

#65

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 complaining about it.

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

#66
I've given up on trying to manage runtime dependencies with language specific tooling. Instead, I've moved to mise which handles the majority of them (Python, Node, Ruby, Terraform, etc.) the same way. It will also activate Python virtual envs:

https://mise.jdx.dev/lang/python.html

It has other nice helpers for development environments (tasks, env variables, etc.).

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

#67
post #25

I have to warn again users that think they have found the silver bullet that pyenv comes with a big caveat: it compiles python on your machine. The number of possible modes of failure in this situation is huge. See also: "Why not tell people to "simply" use pyenv, poetry or anaconda" https://www.bitecode.dev/p/why-not-tell-people-to-simply-use I'm not saying pyenv is not a useful tool, but it is not a tool for beginn…

Actually, it only builds it locally if it can't find a pre-packaged version for your system/arch. Admittedly that's most of the recent ones on a Mac, but there is a difference (I've been using pyenv for nearly ten years[1] now). The big advantage for me is that I can match whatever runtime and standard library a target has (and yes, that's needed more times than not, even in this new age of Docker). Additionally, you…

That happens way more often than people want to admit, and I think it's not genuine to present the tool that way.

E.G, I'm on Ubuntu 20.04 on an Dell XPS, a fairly standard machine, I'll get:

    pyenv install 3.9 -v
    /tmp/python-build.20240325124651.73089 ~
    Downloading Python-3.9.19.tar.xz...
    -> https://www.python.org/ftp/python/3.9.19/Python-3.9.19.tar.xz
    ...
    LD_LIBRARY_PATH=/tmp/python-build.20240325124651.73089/Python-3.9.19 CC='gcc -pthread' LDSHARED='gcc -pthread -shared -L/home/user/.pyenv/versions/3.9.19/lib -Wl,-rpath,/home/user/.pyenv/versions/3.9.19/lib -L/home/user/.pyenv/versions/3.9.19/lib -Wl,-rpath,/home/user/.pyenv/versions/3.9.19/lib  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall'  _TCLTK_INCLUDES='' _TCLTK_LIBS=''  ./python -E ./setup.py  build
    running build
    running build_ext
    ... etc
There are obviously binaries for this Python, since I can apt install it and I didn't specify the minor version.

But by default it downloads the source, and compiles it.

On top of that it will use a shim which comes with its own world of possible pain.

Again, I don't want to bash on pyenv.

But I do want to lower people's expectations.

It's a tool for experts, not beginners.

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

#68

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?

While gross ugly Maven lets you specify the bytecode version and every JDK can produce backwards-compatible jars and has done for many years

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

#69

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?

What package managers are people using in other languages to make sure that software "always works the same as when you first wrote it, without asterisks"? I'd like to understand how they solve the "package no longer exists in a central registry" problem.

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

#70
post #56
post #46

Earlier quoted context omitted.

python -m venv myenv . myenv/bin/activate Ensures you have the same python environment. The other part is OS state.

> 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 you want to package everything up into am image or a zip, you can do that too if you want, but in my 10+ year career I've not had much of an issue just using boring venvs.

Post reply on HN