python team membership
Please add me to the python team (noahm on salsa) so I can help maintain libcloud and potentially other cloud related packages still under the python team's umbrella. Thanks noah
Re: python devs complaining about debian packaging
I remember doing this pull request over a decade ago: https://github.com/broadinstitute/xtermcolor/pull/12/files#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7 to a project that used setuptools + something to download setuptools to be able to use it. I fail to see how that was in any way better than just using what was in the stdlib. Setuptools has always been a weird thing to possibly get rid of… and why have 485 lines of completely unmaintained script to download setuptools when distutils would do? Well I think the author just followed some tutorial or guide at that time. But it was problematic from the beginning that setuptools emerged. And now things are even worse. Even if my post with the link to xkcd got removed from the python discuss, the situation remains the same, with new things to do the same thing being invented all the time. Il giorno lun 3 giu 2024 alle ore 17:57 Paul Boddie ha scritto: > > On Monday, 3 June 2024 16:27:29 CEST Donald Stufft wrote: > > > > In the interim the packaging toolchain evolved to the point that having > > distutils in the stdlib was no longer of general benefit, and in fact made > > things worse because people had grown accustomed to things like `from > > distutils import setup` being transparently monkeypatched to be setuptools > > under the covers. > > The way that distutils could not be relied upon to behave in a sensible way is > entirely the fault of the developer(s) of setuptools having free rein to > corrupt the Python packaging stack. In environments where I wanted to install > to a particular location only the software I had already acquired, which is > largely what the deployment element involved in distribution packaging can be > reduced to, I did not want to be dealing with setuptools when distutils would > do, nor with random hacks introduced to make distutils behave like setuptools. > > For a while, I routinely stripped out unnecessary setuptools references from > setup.py files, put distutils support back in, and mostly got the desired > effect. But in the Python world, once someone teases some fancy new features > and they catch on, everybody else has to hold on for the wild ride and budget > for the consequences. > > (For some software I have been trying to package, I see now that there is no > setup.py or anything else, with some more "magic" introduced to be processed > by yet another tool. I apparently have to get with it, or something to that > effect, which severely diminishes my interest in packaging that software at > all. The outcome actually affects the Debian project directly, not that very > many people seem to care, however.) > > I suppose it also didn't help that distutils entered the standard library in > the era where it was apparently acceptable to get one's code included and to > then declare the job done. Back when Python 3 was initially introduced, I > suggested that the standard library be reviewed and fixed up, especially since > there was going to be a compatibility break anyway, but there was no appetite > for it. > > Still, I appreciate you engaging with this forum, even if it probably means > having to defend decisions made by others. > > Paul > > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io
Request to join the Python packaging team
Hello, I was in the DPMT back when it was on Alioth and I would like to join it again. My Salsa login is "federico". I have read the policy and I accept it: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thank you! -- Federico
Re: python devs complaining about debian packaging
On Monday, 3 June 2024 16:27:29 CEST Donald Stufft wrote: > > In the interim the packaging toolchain evolved to the point that having > distutils in the stdlib was no longer of general benefit, and in fact made > things worse because people had grown accustomed to things like `from > distutils import setup` being transparently monkeypatched to be setuptools > under the covers. The way that distutils could not be relied upon to behave in a sensible way is entirely the fault of the developer(s) of setuptools having free rein to corrupt the Python packaging stack. In environments where I wanted to install to a particular location only the software I had already acquired, which is largely what the deployment element involved in distribution packaging can be reduced to, I did not want to be dealing with setuptools when distutils would do, nor with random hacks introduced to make distutils behave like setuptools. For a while, I routinely stripped out unnecessary setuptools references from setup.py files, put distutils support back in, and mostly got the desired effect. But in the Python world, once someone teases some fancy new features and they catch on, everybody else has to hold on for the wild ride and budget for the consequences. (For some software I have been trying to package, I see now that there is no setup.py or anything else, with some more "magic" introduced to be processed by yet another tool. I apparently have to get with it, or something to that effect, which severely diminishes my interest in packaging that software at all. The outcome actually affects the Debian project directly, not that very many people seem to care, however.) I suppose it also didn't help that distutils entered the standard library in the era where it was apparently acceptable to get one's code included and to then declare the job done. Back when Python 3 was initially introduced, I suggested that the standard library be reviewed and fixed up, especially since there was going to be a compatibility break anyway, but there was no appetite for it. Still, I appreciate you engaging with this forum, even if it probably means having to defend decisions made by others. Paul
Re: python devs complaining about debian packaging
It's not an accurate characterization that distutils was removed simply because it wasn't maintained. It was as fragile library, and it was difficult to make any changes to it because a number of things had implemented themselves by reaching into distutils and randomly monkeypatching various aspects. This made it hard to maintain it _at all_, because when people had tried to improve it, it caused ecosystem wide breakages until things like setuptools, numpy.distutils, etc got patched again. So the unofficial policy became "do not touch distutils", for fear of causing these breakages. In the interim the packaging toolchain evolved to the point that having distutils in the stdlib was no longer of general benefit, and in fact made things worse because people had grown accustomed to things like `from distutils import setup` being transparently monkeypatched to be setuptools under the covers. Ultimately, distutils had diverged so far from modern packaging tooling (due to the unofficial policy of not touching it), that it's existence was more or less a footgun, and it's only real purpose anymore was to be an implementation detail of other libraries, which you had to install from PyPI, so it was decided it was better to remove it rather than leave it around. On 6/3/2024 1:37:32 AM, Salvo Tomaselli wrote: Consider that they are the same people that recently removed "distutils" from the standard library, because it was not maintained. When they have well enough funding to assign someone to maintain it, instead of relying on external projects to install packages. I think they are in the bubble of "people who are here on discuss" and forgot the 99.9% who is not. Il giorno lun 3 giu 2024 alle ore 00:08 Paul Boddie ha scritto: > > 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
