Hacker News Reader

Comment by qwertox | Hacker News Reader

`pyenv` was recommended to me as a way to decouple my Python from the OS's one, in order to be able to run a more current one.

But it has been irritating me more that benefiting me, because apparently I need to recompile Python on every new patch release, also for ARM on a RasPi, which takes forever, and then manage the virtual environments related to it. I can't see it as a solution to my problem.

My problem was that I was using `virtualenv` and when I upgraded Ubuntu 20.04 to 22.04 it blew up all my projects until I recreated all the virtual environments. And I have a lot of them, at least three dozens dispersed on around 15 Linux installations. So I need to find a way to either migrate everything automatically via a script, or use something like `pyenv` to lock my projects to a specific version, so currently I'm holding back a couple of 20.04 installations.

I don't know what to do, this kind of exploded on me, I should have seen it coming.

View on HN

I've answered this before.

The problem pyenv solves is that of programmer's competency. If you are not afraid of building Python, you have no use for pyenv. Python is very easy to compile, it doesn't have a lot of dependencies that need special setup.

As for your question about environments: if you build and install Python yourself, you will most likely use "make altinstall" to do that. This installs Python as /usr/local/bin/python3.X. Then, when you create virtual environment by running "python3.X -m venv" it will always find your Python and will not require any changes if you decide to also compile a different version of Python (because that will end up being python3.Y).

Most likely, what happened is that you ran "python -m venv" and it used system's Python to create it. Once you upgraded 20.04 -> 22.04, you got new system Python, and most of the packages in your virtual environment are now incompatible. You may similarly handicap yourself if you use pyenv: it will just add another level if indirection, but will use unversioned Python executable to create virtual environment.

If you want to salvage those environments, then find out what version of Python you used on 20.04. Compile that, use it to create a blank virtual environment. Copy the old virtual environment directories "lib" and "include" into the new environment, also copy files from the old "bin" directory into the new one, if they aren't already there.

> My problem was that I was using `virtualenv` and when I upgraded Ubuntu 20.04 to 22.04 it blew up all my projects until I recreated all the virtual environments. And I have a lot of them, at least three dozens dispersed on around 15 Linux installations.

Using Nix instead of virtualenv and pyenv might be worth it for you here, though migrating each thing over will be some work.

>But it has been irritating me more that benefiting me, because apparently I need to recompile Python on every new patch release

You don't.

That has also been my experience, could you please elaborate on a solution?

Not sure I follow.

What happens if you install Python X.Y.Z with pyenv and then don't update to X.Y.Z+1? Who'd force you to update or recompile Python?

Major.Minor.Patch. Aren't the patches either security or bug fixes?

Yes, and unless those bugs affect your development in your dev machine you can live without them and only update whenever you feel like it (regarding security, if someone remotely can run their Python code on your dev machine, a security update for your Python version is the last thing that will help).

Or do you mean you use pyenv to handle multiple Python versions in production servers?

Not on production, but as a publicly accessible, nginx-proxied aiohttp server running on a Raspberry Pi. For personal use, like having a long-lived WebSocket connection to my home server.

I generally thought it was best practice to always update to the latest patch release. I mean, that's what `apt` is doing for the system-installed version.

>I generally thought it was best practice to always update to the latest patch release. I mean, that's what `apt` is doing for the system-installed version.

Well, if it's publicly accessible, yes. Though even there you don't just "update to the latest patch release" you need to check it first (at least with your test suite), it might break your functionality and even introduce security issues due to that, regardless of what the upstream "semantic" versioning implies.

Reply on news.ycombinator.com