On Thu, Oct 29, 2026 13:03:44 +0100, Cristian Le via devel wrote: > On 10/29/26 12:46, Michael J Gruber wrote: > > > Hi there, > > while it's fall in some parts of the northern hemisphere and autumn in > > others, some thoughts on leaf packages, especially in language > > ecosystems. > > > > Those thoughts are triggered by upstream changes in a python package > > that I maintain. I spent quite some time keeping it building in > > Fedora, and now trying things to follow the upstream changes according > > to our packaging principles, but I'm finally wondering: > > > > What for? > > If it was possible to pip install and try to resolve from dnf first before > going to PyPI, it might not be as problematic. On the developer's side it > gets quite frustrating when you have a dependency that is compiled and there > is not a compatible version in PyPI so the package needs to be built from > source, and then you hit issues of not having compilers, etc. Every year I > get this issue with pydantic-core. And heads up ruamel.yaml.clib will not > have python3.15+ versions at all. > > Another aspect is the python-sig's very early rebuilds and incompatibility > detection. I find that many of those bugs are filed by someone in our > sphere, especially when upstream can't do early tests themselves because of > :point_up:. > > I do agree that many packages would generally need little actual work, but > maybe the workflow can be made smoother?
I think there are two different use-cases here. One is us, looking at the latest python version. This is us helping test packages on the latest Python version before it's released. For this, packaging is sort of important I guess, since we need to test with a bunch of new software versions. Although, for quite a few upstreams that we notify, the response we get for bugs is "well, we don't have access to this new python version on my CI, so I can't fix it until it's released". Or the plainer: "we'll fix it after release". Fair enough on both counts. The other use case is end-users. I don't think a lot of them, especially non developer users, are looking to use the latest Python. In academia, it seems to be the opposite: users keep using old, "stable" versions of Python until they are forced to move to a new version---because they don't have the time to fix breaking changes and update their scripts. They want stuff that "just works" and "keeps working". Also fair enough. As also noted, a lot of people do need specific versions etc., and using virtual environments is the norm. For the neuro-sig, we've been trimming down our Python packages. We only package software and deps that requires compiling (so answering Cristian's issue). For others, we just test that they install correctly via `pip`. At the moment, it's a rather hacky pytest based check running on my machine that spits out results here every Monday and updates our docs to note issues: https://ankursinha.fedorapeople.org/neurofedora/package-status/latest/ https://forge.fedoraproject.org/neuro/NeuroFedora/src/branch/main/python-package-usage-check/run-suite.sh I have it on my TODO list to improve this to file notifications/tickets for us. Ideally, these tests should be done on upstream CI already---but it's useful for us to have a central table of software that is relevant in our docs. eg: https://docs.fedoraproject.org/en-US/neurofedora/compneuro-tools/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
