>That Python environment isn’t for you.

This is a relatively new and dangerous way of thinking about operating systems. Due to the massive futureshock of libs rapidly changing under-foot people have had to switch to containerization as a mitigation. And now people have been containerizing so long they are starting to believe it is the proper way to do things.

It's not. Giving up the idea of an operating system with system libraries is very bad. The idea that you have to set up an entirely new lib environment to run every single script is absurd and it has dire consequences for software longevity and portability. With no more OS system as a base an OS is fractured into literally innumerable possibilities. Gone is the idea of a distro being the same for everyone using it. Gone is the ability to just install things. And we're left with a pile of containers that make debugging things when they go wrong even harder.

Nix is taking this concept to the extreme and absurd, but using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue.

> This is a relatively new and dangerous way of thinking about operating systems.

One could as well say: this is a response to faster-than-ever evolving platforms.

> Giving up the idea of an operating system with system libraries is very bad.

Good point. I don’t like the situation either.

I’m not sure there’s a good remedy. For example, how are system package maintainers supposed to know that your personal script is now ready to migrate, so they can finally bump system Python?

> using pyenv for every script is almost as bad. pyenv is not version management approach to Python. It's a bandaid that doesn't address the actual issue.

Not sure if I’m understanding you correctly here. You’re saying that using pyenv for every script is bad. Are you against venvs, too? Because you could apply a similar argument to those.

This x100.

If your project requires dozens of installed libraries to use even it's base features, that tells me a lot about you and your project.

Mainly, it tells me you haven't thought about stability and the future of your application.

That’s a false dichotomy.

Firstly, this is about the core platform, not third-party libraries.

Secondly, I absolutely do keep all my projects in lock-step with the latest stable platform version. My point is that I do that deliberately and in a controlled way, decoupled from my system package manager’s decisions.

I certainly don’t appreciate waking up to dozens of unexpected compile errors and warnings due to some random system Python version bump.

> Don’t use your system’s (or even your system-level package manager’s) Python environment for your Python projects.

I get the reasoning but I disagree with this as a blanket statement.

For my own stuff, I stick with certain OS versions that I know and trust. If I standardize on Ubuntu 22.04 for example, I know that it will only ever ship Python 3.10 (plus patch releases). If I ever need another version, that's what the deadsnakes repositories are for. Ubuntu is never going to spontaneously upgrade the `python3` package to 3.11, especially not in an LTS release.

I understand the situation is different on Mac (and possibly Windows?) as they have a history of shipping outdated (and/or broken) Python environments and any system upgrade has the potential to bump your Python version.

Python's virtual environments may be somewhat clunky but it's entirely possible (and not even that hard) to keep project libraries and dependencies completely isolated from the system's with the various venv tools that exist these days.

At work, we have a large in-house ecosystem of scripts, modules, and packages written in Python so it's easier to tell developers, "pyenv is our supported Python environment, use anything else at your own risk."

Thanks for the insights!

You’re right of course; I’ve never really used Ubuntu, so I’ve never come to enjoy that level of stability.

I used to have a Mac, which is shipping with outdated platforms, and used Homebrew on it, which has a rolling-release model. I’ve switched to Arch since, which also happens to be a rolling release. That’s the context I’m coming from.

> Ubuntu is never going to spontaneously upgrade the `python3` package to 3.11, especially not in an LTS release.

Even then, your teammate may use a different LTS or even different distro than you do, ending up using a different Python version on your project than you do. I wouldn’t be willing to deal with that drift.

> Python's virtual environments may be somewhat clunky but it's entirely possible (and not even that hard) to keep project libraries and dependencies completely isolated from the system's with the various venv tools that exist these days.

Absolutely. However, even when using venvs, I still don’t want my venv to point to /usr/bin/python. Hence the `pyenv install -s && pyenv exec pip install poetry && pyenv exec poetry install` instead of just `poetry install`.

Windows doesn't ship Python out of the box at all, so there's no "system-level Python" there. The closest you can get to that is installing it from the app Store, but each major Python version gets a separate package there.