@mgorny@social.treehouse.systemsSo I've just bumped a bunch of old #Gentoo packages to EAPI 8. Some of them haven't been updated for 6 years. And do you know what's best? They still worked — their build systems work, they compile and they just work. Unlike most of the stuff developed these days.
#autotools #C
@mgorny@pol.socialWłaśnie zaktualizowałem trochę starych paczek #Gentoo do EAPI 8. Niektóre nie były aktualizowane od 6 lat. I wiecie, co jest najlepsze? Że nadal działają — systemy budowania działają, kod się kompiluje, programy działają. W odróżnieniu od większości nowego oprogramowania.
#autotools
@mgorny@pol.social @mgorny@social.treehouse.systemsSo #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.
The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.
It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.
What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.
Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.
In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.
But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.
@mgorny@pol.socialA tak poza tym, to wysłałem parę łatek, by ulepszyć funkcję epytest w #Gentoo.
Wymuszają krótkie podsumowania, załączają tworzenie plików junit .xml, żeby ułatwić maszynowe przetwarzanie wyników, i — co najważniejsze — dodają zmienną EPYTEST_PLUGINS, żeby podawać, które wtyczki mają być załadowane. Będziemy dążyć do tego, by całkiem odejść od domyślnego automatycznego ładowania wtyczek.
@mgorny@social.treehouse.systems @mgorny@pol.socialBiblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1&…
@mgorny@pol.social
@thesaigoneer@social.linux.pizzaHaving said all that and more: nothing atm comes close to gentoo with dwm. Bar my fav slackware of course 😄
#gentoo #slackware
@portaloffreedom@social.linux.pizza @mgorny@pol.socialNieudany poranek z nowymi wersjami paczek Pythona dla #Gentoo:
1. Projekt, który zwlekał z wydaniem nowej wersji z poprawkami bezpieczeństwa 4 lata, w końcu wydał nową wersję. Oczywiście, jak się robi jedno wydanie na 7 lat, to definitywnie trzeba w tym czasie zmienić system budowania na zepsutą hybrydę #PythonPoetry
@mgorny@social.treehouse.systems @mgorny@pol.socialZdradzę wam sekret: nazwa "portage" pochodzi od pora — tego warzywa.
#Gentoo
@mgorny@pol.socialPaczka Pythona, której nie idzie zainstalować na Pythonie 3.14, bo autor koniecznie musiał zaimplementować przetwarzanie AST na ponad 200 linii w `setup.py`? Dlaczego nie.
#Gentoo #Python #setuptools
@mgorny@pol.socialPaczki Pythona:
"A pamiętacie tę całkowicie przypadkową wtyczkę PyTesta, która nie jest rozwijana od 2018 roku, i którą musieliście dodać do #Gentoo, bo postanowiliśmy jej używać bez jakiegokolwiek powodu? No cóż, właśnie przestaliśmy. A tak przy okazji — właśnie udało nam się znaleźć kolejną wtyczkę, która po raz trzeci wynajduje na nowo obsługę niestabilnych testów. Miłej zabawy!"
@mgorny@social.treehouse.systemsModern programmers: "oh, let's hijack all #Python package managers in your bashrc without asking for consent, what could possibly go wrong."
And the best joke is, I didn't even really install the package — I was just making a random bugfix and running its test suite in a virtual environment.
#Gentoo #security
@mgorny@social.treehouse.systemsIn other news, I've sent a few fun patches to improve epytest in #Gentoo.
This includes forcing short summaries, creating junit .xml for machine processing, and most importantly, EPYTEST_PLUGINS to handle specifying the plugins to load. The goal is to eventually move away from plugin autoloading by default.
#PyTest #Python
@mgorny@social.treehouse.systemsA bad #Python bump morning in #Gentoo:
1. A project that couldn't be bothered to make a release with a security fix for 4 years finally made a release. Of course, if you make one release in 7 years, it is definitely a good idea to replace your build system with a broken #PythonPoetry #setuptools hybrid.
2. Another project made a release with a bunch of test failures — that were fixed in "master" branch already at the time, but I guess nobody bothered testing the release branch.
3. Just discovered that a bunch of projects are using pkg_resources namespaces again — and we were supposed to have gotten rid of them years ago! Of course it's #Google. And on top of that, since pkg_resources are now throwing deprecation warnings, they are indirectly breaking random other test suites.
On the positive side, test_lolwut is failing for me in redis-py.
@mgorny@social.treehouse.systemsThe time has come for me to propose that #Gentoo leaves #GitHub.
#Microsoft has been purveying #enshittification of this platform for years now. Pushing #Copilot everywhere was the last straw.
#AI #LLM
@mgorny@social.treehouse.systemsA #Python package that can't be installed on Python 3.14, because the author had to implement a 200 line custom AST parser in `setup.py`? Yeah, why not.
#Gentoo #packaging #setuptools
@mgorny@social.treehouse.systems @mgorny@pol.social @mgorny@social.treehouse.systemsNowadays in quality #Python: #Gentoo is running #ProtoBuf-related test suite via #PyTest-forked to workaround protobuf segfaulting during GC.
Of course, it implies random programs can segfault on exit too.
https://github.com/protocolbuffers/protobuf/issues/22067
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/protobuf/protobuf-6.31.1.ebuild?id=54e20d4bb0ec99ab868695a2980c4307d179cb10#n150
@mgorny@pol.socialKiedy poświęcasz godzinę na zaciągnięcie poprawek bezpieczeństwa do wszystkich wersji Pythona w #Gentoo, bo właśnie weszły do repozytorium CPythona i nie było nowych wydań w planach — a kilka godzin później znów poświęcasz czas na zaktualizowanie paczek do nowych wersji, które jednak wydano.
No i oczywiście po drodze dziwisz się, dlaczego nie zamaskowałeś 3.8 poprzednim razem, i drugi raz popełn…
@mgorny@social.treehouse.systemsDays since a random #setuptools project migrated to `pyproject.toml`, removed `MANIFEST.in` and broke source distribution in the process: [0].
#Gentoo
@mgorny@social.treehouse.systems#Python #packaging be like:
"Remember the totally random #PyTest plugin that died in 2018, that we forced you to add to #Gentoo, because we decided to start using it for no good reason? Well, we just stopped. Also, we just found a #NIH plugin that reinvents flaky test handling for the third time, enjoy!"
(Fortunately, it's compatible enough with pytest-rerunfailures, so we can ignore it.)
@mgorny@pol.social @mgorny@social.treehouse.systems#PyYAML rejected #freethreading support. As a result, a new fork has been created with freethreading support. Given the fork's focus on freethreading, it supports only Python 3.13 . Given the lack of environment markers for freethreading (yet), packages end up depending on PyYAML-ft for >=3.13 (including non-freethreading builds), and PyYAML for <3.13.
Isn't #Python #packaging great?
#Gentoo
@mgorny@social.treehouse.systemsWhen you spend an hour backporting #CPython #security fixes to all versions of #Python #Gentoo, because there was no planned security release, and a few hours later you spend time again bumping to the unexpected security releases.
And then you are surprised why you didn't mask Python 3.8 yet, and repeat the same mistake.
Oh, and ofc update your CPython and PyPy (fixed PyPy only in Gentoo).
@mgorny@social.treehouse.systemsNew reason not to use #PythonPoetry just dropped: they reinvented "reproducible builds", poorly. The problem is, they missed the purpose of reproducible builds entirely and they use it for source distributions too, and when you don't use SOURCE_DATE_EPOCH, they force all files to epoch (as in timestamp 0) instead of leaving them alone.
Like, all source distributions created by Poetry and uploaded to #PyPI now have 1970 timestamps that, simply speaking, break stuff. The most absurd thing is that ZIP can't handle that timestamp, so they override it and use another date for wheels 🤦.
#Gentoo #PEP517