> For example, by running ``sudo pacman -Syu`` I upgrade everything that is installed, including the kernel, standard libraries, Python packages, language packages, manpages and so on.
I actually view this as a liability. System package management should be distinct from userspace package management.
You can still use pip inside pyenv or similar. Pacman would install the system-wide stuff, so you won't need to bother about the libraries that a package that you have installed is using.
Mentioning this classic XKCD: https://xkcd.com/1987/. This only made sense after using a Mac. While using Manjaro it was quite organized: only the pacman-installed libraries and the ones of my user projects. Now in Mac I have the default Python, the several Python versions installed from several dependencies in Homebrew, and so on.
Most system-wide stuff is userspace. I was more referring to a divide between the OS-core (kernel, drivers, init scripts) and userspace. Upgrading userspace should not incidentally not allow the system to boot.
It won't happen if the packages are well maintained. Note that if you want a different version for your project you should use a pyenv or similar and have finer control on its dependencies
A pyenv is separating system and user / project packages. You could take it one step further and use pkgsrc, Nix, or homebrew. That way you can get a newer redis/RabbitMQ/whatever not just newer python.
I actually view this as a liability. System package management should be distinct from userspace package management.