Live data from Hacker News

Pyenv – lets you easily switch between multiple versions of Python

github.com

81–90 of 341 posts

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

#81

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.

Point of clarification: asdf uses python-build which is from pyenv.

https://github.com/asdf-community/asdf-python?tab=readme-ov-...

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

#82

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…

I generally like bite codes newsletter but this one was a miss for me.

I’m sure he is trying to promote some sort of work flow in that article but I don’t understand which.

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

#83
post #46

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?

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

In this case you don’t count the standard library as part of your Python environment. Since Python version is not specified neither is the standard library.

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

#84
post #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 complain…

Just getting me and one coworker in sync on our dev machines often causes problems. Even more when we try to deploy to a cloud service which relies on pip.

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

#85

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?

None. The software container image is the best bet but you need to keep the image and not only the building scripts.

Yeah, containers don't fully solve this problem.

We still need a generated lock file with every top level dependency and sub-dependencies locked down to their most precise version commit to version control so that when you build your image today or in 6 months you end up with the same result.

Using pip to freeze your dependencies and writing a tiny shell script to generate a lock file at build time is better than nothing to solve this problem with nothing more than pip. It's what I do in https://github.com/nickjj/docker-flask-example and https://github.com/nickjj/docker-django-example. It's not perfect but it solves 80% with minimal complexity.

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

#86
I'm using pyenv to manage different projects on my machine. I use --system-site-packages to share libraries like torch, and some others -- especially to ensure those libraries are built with the same cuda version, avoid some issues when upgrading drivres, and to avoid having to keep multiple copies of several gigabyte libraries around.

I'm not using things like anaconda for a similar reason I'm not using docker. -- I don't want a separate OS install for each service I'm running on my server. It works perfectly fine.

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

#87

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…

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

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

#89

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 didn’t miss Poetry, but I have to say up until I started using Poetry python in large projects was a pain in the tooling department to setup and maintain over longer periods of time.

It’s no panacea, but feels more stable and usable (especially from onboarding new team members PoV) than other tooling I’ve tried

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

#90

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…

If you use Homebrew: you can use ‘brew pyenv-sync’ to use Homebrew’s pythons with pyenv. Similar commands are available for rbenv/nodenv (which always feel like it is missing an ‘e’ to me)
Post reply on HN