Re: python devs complaining about debian packaging

[Paul Boddie <paul@boddie.org.uk>]

On Monday, 27 May 2024 04:07:34 CEST Scott Kitterman wrote:
> 
> While there are technical concerns on both sides, socially I think the
> Python community isn't that interested in outside perspectives.

I managed to dig up these notes from the packaging summit at PyCon:

https://hackmd.io/@pradyunsg/pycon2024-pack-summit

Here's the summit page itself:

https://us.pycon.org/2024/events/packaging-summit/

There is some fixation on the "system Python" in distributions, and the 
following remarks:

"At least one distro team is working on moving their own Python out of the 
way, so users can install their own Python packages [...] Fedora tried 
platform-python and it broke everything, so it didn't really work"

Given the proliferation of "virtual environments" around Python, where you 
just pick your own Python version and accompanying packages, I find it odd 
that the Python packaging community gets so hung up on the system Python. Do 
they want it to just go away or not be on the path or something? Wouldn't 
having a singular upstream Python just cause the same problems when someone 
finds that it isn't the version they need?

For my own amusement and to confirm my own memories, I went back in time to 
check the Python Web site in the 1990s, and back then there was no problem in 
providing a binary for Linux and the Unix products of choice from that era. 
AIX, FreeBSD, HP-UX, Irix, OSF/1, Solaris, and SunOS 4, plus a Linux binary 
supplied either as an RPM or in a plain archive:

https://web.archive.org/web/20021030010019/http://www.python.org/ftp/python/
binaries-1.4/

What is stopping anyone from doing that all over again? The user downloads the 
binary, puts it in their current directory, and runs their software. Could it 
be that the burden of support is perhaps a little greater than one might 
expect?

Because from that starting point, you have to build multiple versions, and 
then you have to build accompanying libraries, and then you have to support 
third-party packages which need third-party libraries. It wasn't a surprise 
that things like Sun Freeware (http://www.sunfreeware.com) emerged to cater to 
the proprietary platforms, whereas distributions emerged around Linux to 
manage this complexity and provide all this software.

It is easy for the various language communities to focus only on their own 
ecosystems, but everybody's software has to work together. And then there are 
companies targeting various markets that demand software built on a selection 
of different technologies, so you get perspectives like these:

"Why did the PyPI and Conda ecosystem get created? It was originally created 
as an educational teaching language. If all of your tools are in Python, all 
of the things in your ecosystem are supposed to work well together. However, 
the tools that scientists and data scientists use are very commonly written in 
C, C++, etc. and so there’s something called a “native binary problem”. Making 
this stuff compatible across the board is an incredibly challenging issue! 
Conda was created to resolve those binary compatibility issues."

I honestly don't know what these people think operating system distributions 
are doing if not solving the "native binary problem".

Paul