| > 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." |
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`.