It is super annoying how Debian and Ubuntu try to force their users to install distro-specific deb packaged perl and python modules.
This makes Debian/Ubunto a no-go if you need to do something that is not very common, ubiquitary and ordinary.
So I had to ditch the idea to install that new specialty server on Ubuntu.
Now it will be installed on OpenBSD instead.
I’d be really interested to know the rationale behind the rejection of cpan and pip by Debian and Ubuntu!
Does anybody know?
Regarding PIP, Ubuntu simply respects upstreams wishes to keep them distinct (I assume debian does the same here):
Yup. I’m actually surprised there are still some distros out there that don’t comply with #PEP0668 and allow pip install outside of a virtual environment. Doing that nowadays is playing with a high-calibre footgun.
I don’t think Debian and Ubuntu are against pip, and such. However, the vast majority of system dependent resources in Debian and Ubuntu require a fixed Python version so nothing breaks. That’s done during the release cycle.
I’ve posted about this on Ask Ubuntu before, but if you need multiple or updated Pythons, you might consider using pyenv to setup and install other Python versions in your userspace, as well as create/utilize virtual environments managed by it. That way you can use pip to install things.
Additionally, you’re free to install in Ubuntu from the deadsnakes PPA coinstallable newer Python versions for specific needs, and then directly refer to those versions for execution python3.13 for example instead of just python3orpython`) and then build venvs for use under that.
This said, in Python 3.12 and later per PEP-0668 as referenced enforces the external environment restriction to not use pip to mess with system installed packages. That can be overridden, but the proper way even with a system Python install yourself in userspace is to use venvs to keep the ‘core’ installation clean whether it’s pacakge-manager installed or compiled yourself and installed in userspace or otherwise.
This is more Python upstream following its protocols, and such.
Usually I see this with older Python versions than 3.11/3.12, rather than distro-specific choices.