Re: python devs complaining about debian packaging
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 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 wrote: >Hi Ian (2024.05.26_01:33:09_+) >> 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]
Re: python devs complaining about debian packaging
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 wrote: Hi Ian (2024.05.26_01:33:09_+) > 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]
Re: python devs complaining about debian packaging
Hi Ian (2024.05.26_01:33:09_+) > 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
Re: python devs complaining about debian packaging
That's just too crazy to let change a core system dependency so easily from outside.
Re: python devs complaining about debian packaging
I'll just say that the equal amount of FUD and ranting can be easily generated abotu Debian or even just about Debian Python packaging. -- WBR, wRAR signature.asc Description: PGP signature
Re: python devs complaining about debian packaging
Hi, I have always found most of issues mentioned in the thread a welcome change instead, and if anything the far superior ability of apt to automatically remove all the installed dependencies in case of the removal of a package compared to the complete inability of pip has always left me in awe. I doubt they are really weighing the tradeoffs enough before choosing to hand out the blame. Best, Ananthu
Re: python devs complaining about debian packaging
On Sunday, 26 May 2024 03:33:09 CEST Ian Norton wrote: > 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. Or whatever today's tool is called. That's just one of the problems that the core Python packaging scene has. To be fair, though, I found myself using pip in a job a couple of years back just to "go with the flow", and it mostly worked. My expectations were not particularly high, however. Where I was just installing things casually, I made pip install things using the --user option, which employs that unpleasant but pervasive approach of stashing huge volumes of software inside a hidden directory (something things like Plasma also do), where one wonders where all the disk space has gone. There's also the issue of uninstalling unwanted software, which probably still isn't solved. Where I was installing things in a Web application environment, I made pip install in a designated directory, but I seem to remember having to do a fair amount of environmental configuration to make sure that Python and Apache were able to find all the modules. I guess I could have used virtualenv, venv, pipenv (see what I mean?), but one is left wondering how all of these things interact with the rest of the system. How does one make Apache "enter" the virtual environment of whichever flavour, for instance? (Yes, "containers" exist, but I am reminded of the saying about solving problems with regular expressions: now you have two problems. Particularly with the inelegant way Linux provides support for containers.) With the fundamental Python packaging technology, the one thing that seems to have improved somewhat is the availability of wheels - whose implementation is probably heavily underappreciated - which avoids the issue I previously had where a source package is downloaded by pip and then fails to compile in a bad way. Twenty or so years ago, people wanted to replicate the CPAN experience for Python, but I doubt that this was what they meant. The Python core developers have always complained about distribution packaging and distributions "ruining the experience for users", all reported rather selectively, but this is a situation much of their own making. They have always wanted to do everything themselves, traditionally with the justification that Windows and the Mac have to be catered for. People used to band around the term "stop energy", but pandering to Microsoft and Apple seemed to be a significant source of that energy. Meanwhile, there are competing but incompatible tools like Conda that do everything themselves, too. When deploying things conservatively using pip, I had it suggested to me that I should use Conda. Conda's shared libraries are incompatible with the way Apache is built on Red Hat systems, so the proposed "solution" was to run the Web application using the built-in Python Web server and to proxy it using mod_proxy in Apache. What a joke! So, the core developers make their own package repository, downloader, dependency resolver, installer, environment manager. At many an opportunity, they had the opportunity to leave this particular highway of madness, but they raised the stakes and now are in the business of effectively running their own "app" store, all without Big Tech's legions of low-cost workers trying to prevent malware being part of everyone's next invocation of "pip install". I could be rather cynical about some of the motivations of people in the core development community. I see that a few of the discussion participants have worked for Red Hat and at least one of them was involved in the enthusiastic deprecation of Python 2 on the basis that people could always pay for continued support. No coincidence that RHEL is where people will go for that support, I suppose. And these discussions have always had the tone of people pontificating about what "the users" want or do, even speaking for them, and yet never really engaging with the actual users. Combined with a lack of appreciation that most users run other software that isn't written in (or for) Python, probably because Windows doesn't provide such software out of the box. Some actual users are still running Python 2, believe it or not, regardless of whether that can be seen from the ivory tower. In case anyone thinks this rant was a bit unfair, I followed the Python mailing lists for almost a couple of decades and saw plenty of discussions on such matters on python-dev. Then again, I think the stewardship record of the Python language over the last twenty years rather speaks for itself. That is a statement left for one to interpret in the way one feels most comfortable with. Paul
