Are you talking about Docker as a technology or Docker containers as offered by https://hub.docker.com/_/python ? As of the former, I don’t see any reason why it cannot be done well, and actually I believe most larger Linux distros provide some set of Docker containers with their packages for Python and other languages (I know, we, SUSE, do).
The same (multiple versions of Python installed at once) is true on many Linux distros, it is certainly true on openSUSE/SLE that you can install multiple versions of Python interpreters (and all related packages) in parallel.
Sure but to me it comes back to user experience. Lots of folks would be happier to not need to hit the terminal to do installs.
We also still hear of people accidentally replacing the system Python every once in a while so it definitely happens.
1 Like
Then use the GUI installers?
1 Like
Afaik doesn’t exist for Linux. Hence this thread.
1 Like
Yes, currently Python 3.8 - 3.13 are provided on Factory/Tumbleweed, Python 3.6 and 3.11 for SLE/Leap (and various other distros in different Services Packs), together with various number of packages (so we have python311-requests for example).
And yes, we have still Python 2.7 in Factory, but that is mostly because it is dependency of Gimp. Whenever they release Gimp 3.0, Python 2.7 will go from Factory/Tumbleweed.
1 Like
What does not exist for linux? There are GUI installers for packages so you can install python without needing to use a terminal.
1 Like
People search for python download, get to python.org, then don’t find a Linux installer option.
Barrier to entry is higher than in Windows already based on that.
5 Likes
This is the way. I tried it with python 3.6, that I was not able to compile anymore on my ubuntu 22.04, and it worked. For me this is enough.
Whoa, wait a minute. I didn’t say I don’t like conda, I said that it’s not standard python
It’s not unusual at all, on Pypi it’s common to have a fallback in pure python if your c extension is not available for a specific platform. This seems to be impossible to publish on conda, because conda give priority to the pure python package, so you always install the pure python package on every machine. On the contrary, pip gives priority to the platform specific package.
Maybe it’s a problem that doesn’t exist, since conda for what I know is not available to all platforms the standard python supports.
Okay, so its a documentation issue then.
For linux python.org needs to state that python is conviently provided by the distro itself. It can also go to show for popular distros what you need to do to use python, is it already installed, do they need to install a package.
3 Likes
It could be a bit of both. I think a middle ground could be to just link some common distro guides. Though in a perfect world a manylinux installer that happened to work in most places would be nice still.
1 Like
It’s not just a documentation issue. While RHEL Redhat, and SUSE (and a few others) have been great in terms of meeting user expectations, Debian and Ubuntu have not. Much much earlier in the thread, it was highlighted that the majority of issues caused by this is a clash between debian policy and cpython, and user expectations and that this is not a universal issue on linux.
I don’t think the goal here was to force any distribution to do anything differently, only to provide a better out of the box experience for users whose redistributions are doing something incompatible with their needs. This was also not meant to mean all redistributors are doing something wrong.
4 Likes
Most distributions treat packaging Python to as just providing one dependency that an application/tool written in Python will have. It’s not there to be a developer environment. And juggling multiple versions of anything is something they actively avoid.
Whatever the answer is, it’s unlikely to include the native package manager (or at least not without private package repositories).
3 Likes
Then make that clear to users. Maybe engage with debian pythin maintainers to help solve the problem.
That is not true in my experience on Fedora/rhel and as @mcepl made clear not true on OpenSUSE either.
Is this all about issues with debian/ubuntu?
(I am not up to speed on *BSD at the moment)
That’s been done for years, history on this was shared as one of the first few messages in the thread, and debian policy is at odds with user expectations here, so it seems like nothing will change. Rather than shift blame around, this thread is attempting to have a more user-friendly solution provided by python
3 Likes
It is possible, and easily so. If you have a specific example of a package (say, in conda-forge) that needs this, feel free to ping me how to do it. That said, the “natural” way in conda is simply to ensure that the package with the correctly compiled C extension is available for every platform of interest, which avoids the question of the fallback in the first place (if a given target is not yet supported by conda and its channels[1], it’s going to be pointless to use conda anyway).
in conda-forge, that’s
linux-64,linux-aarch64,linux-ppc64le,osx-64,osx-arm64,win-64, and hopefully sometime soonwin-arm64resp.emscripten-wasm32. ↩︎
2 Likes
For the record, Fedora ships 13 versions/variants of Python interpreter (CPython 2.7, 3.6 to 3.13, PyPy 2.7, 3.9, 3.10, and MicroPython) with different levels of support. RHEL and CentOS have fewer Python versions (c8s: CPython 3.6, 3.8, 3.9, 3.11, 3.12; c9s: CPython 3.9, 3.11, 3.12). The additional Python versions are designated for development, testing, and to run user applications.
Then the issue is a need to provide better support for debian/ubuntu python users?
My point is just that they’re outliers and that it’s not a cheap or expected (by maintainers) feature (learning to write OpenSUSE .spec files is considerably more difficult than say Arch’s PKGBUILD because everything needs to be wrapped in for each version of Python macros). I can’t imagine a simplicity focused distribution like Arch or Alpine ever saying yes to doing this. I also can’t imagine Debian ever surviving this policy (debuild is already more complex than any other build system I’ve used). And multi Python version suppport would probably wreak havoc with Debian’s policy of moving /usr/lib/pythonx.y/site-packages to the version agnostic /usr/lib/dist-packages.