Overall, I think that's quite reasonable, but I think I need to pick at the both sides way this is framed.
I don't recall anyone here suggesting that it's a problem is Python upstream wants to ship Python binaries. While I think that there are issues with some of the upstream design choices, I understand why upstream packaging exists. Debian leverages it to deliver our system. I do find the common view upstream of distributions shipping anything Python as a problem to be super annoying. Not you, to be clear. I think you are one of the few people that does see both sides of the problem. Personally, I've given up on any upstream interactions. I don't need pointless hostility. While there are technical concerns on both sides, socially I think the Python community isn't that interested in outside perspectives. Thanks for sharing your thoughts, Scott K On May 26, 2024 11:23:03 PM UTC, Donald Stufft <don...@stufft.io> wrote: >I happen to be subscribed here, so figured I'd comment :) > >FWIW I think the way the discussions are going... really in both locations.. >is needlessly taking shots at each other. > >I've commented on discuss.python.org, but figured I'd repeat myself here. > >I think the way these discussions devolve into each "side" taking shots at >each other and arguing over nonsense that doesn't matter does everyone a >disservice. > >The facts of the matter, as far as I can tell: > >- Distributors ship Python and a number of people find great value in that and >it works great or at least fine for them. >- A number of users have needs or wants that are not well served by the Python >that distributors ship, for one reason or another. > >People in either of those groups sniping at each other for wanting the "wrong" >things is completely unproductive. > >It's probably "fine" if Python.org wants to ship a linux binary, I suspect >it'll have very little impact on distributors of Python (and might even make >things better-- since some of the problems flow from an impedance mismatch, >and it provides a different escape hatch to point people towards if the distro >Python doesn't suit their needs). > >On 5/26/2024 9:39:25 AM, Stefano Rivera <stefa...@debian.org> wrote: >Hi Ian (2024.05.26_01:33:09_+0000) >> I am puzzled about some of the responses there, how can anyone expect to >> randomly update packages on the system using pip and not have it go wrong >> on any distribution? This is why things like pipenv exist. > >People don't understand that stuff until they dig to the details. And >even then, sometimes they forget and/or assume we have the resources to >massively revamp our stack. > >There are long-standing grievances here (see tiran's gist for example). >I have very little experience with Fedora/RH, but from their grumbling, >I assume they solve some problems for developers that we don't: > >1. It appears that multiple versions of cPython are trivially available. >Each version has its own site-packages. >2. Their python packaging is more developer-centric than user-centric. >More modules included in the install. > >We're pretty constrained on 1 by the debian security team policy. But >maybe there is discussion room there for non-supported Pythons? > >We have taken steps to improve 2 by adding the python3-full package. > >I could see a long term strategy for having a system-python package that >provides a python3 binary used by Debian packages that need Python. And >a separate python package for developers that installs all the bells and >whistles immediately. > >Achieving this would require reorganizing the way we package almost all >Python, and I don't think we have the interest and resources to do that. > >If pyenv was packaged in Debian (ITP #978149) it would probably be great >for new Python developers on Debian. > >Not sure what other small tactical steps we could take? > >> > Perhaps someone else wants to comment on that conversation > >Replied. I've engaged with these guys on this stuff before. Let's see >where it goes... > >Stefano > >-- >Stefano Rivera >http://tumbleweed.org.za/ >+1 415 683 3272 > > >[163d8144-a584-4d1d-9d71-f86da864fde2]