#Gentoo is also going "full #PEP517" now, or to be more precise, we are going to rip out the legacy code paths that used `setup.py install`. However, that doesn't mean that PEP517 support is a solved problem.

1. There are still packages that require `setup.py install`, and either outright reject or ignore PEP517. And I'm not talking of dead packages but actively maintained projects. #Fail2Ban is a particularly notorious example (the way I see it, it's going to stop working sooner or later).

2. Some packages that do work with PEP517 builds, still require some hacks to install correctly. Sometimes it means moving files around, sometimes installing some files manually, sometimes patching stuff.

3. There are many packages that use the legacy setuptools backend to workaround their broken PEP517 port. Fortunately, these are at least easy to fix, provided you can convince upstream that actually altering sys.path is the correct solution.

4. Finally, we have removed a fair bunch of "hopeless" packages.

#Gentoo przechodzi na "100% #PEP517", a dokładniej, to usuwamy kod wspierający `setup.py install`. Nie oznacza to jednak, że ekosystem doczekał się bezproblemowego wsparcia dla tego standardu.

1. Nadal mamy paczki, które wymagają `setup.py install`, i albo odrzucają, albo ignorują, PEP517. I nie mówię tu o nierozwijanych starociach, lecz aktywnych projektach. #Fail2Ban jest tu przykładem wartym nagany (jestem przekonany, że prędzej czy później przestanie działać).

2. Niektóre paczki działają, ale wymagają obejść. Czasem trzeba przerzucić pliki po instalacji, czasem trzeba doinstalować jakiś brakujący plik, a czasem coś połatać.

3. Wiele paczek nadal wymaga przestarzałego ("legacy") backendu setuptools, by obejść problemy z portem na PEP517. Szczęśliwie, z reguły łatwo się je naprawia, o ile uda się przekonać autorów, że modyfikacja sys.path to właściwe rozwiązanie.

4. No i sporo paczek, dla których "nie było nadziei", wyleciało.

Skoro już ugaszono te największe pożary, porozmawiajmy o innych fajnych rzeczach, które dzieją się z #setuptools.

Na ten przykład, setuptools niedawno zaimplementowało PEP 639 (nowe metadane, dotyczące licencji). Przy okazji oznaczyli swoje poprzednie pole `license-field` jako przestarzałe, dając ludziom czas do 2026-02-18 na podmianę. Ostrzeżenie podpowiada też, że nowe pole wymaga setputools w wersji 77, którą wydano… tydzień temu.

No więc setuptools praktycznie mówi nam, że mamy do wyboru: albo używać starego rozwiązania, które oznacza, że wszystkie używające go wersje paczki przestaną się budować w lutym przyszłego roku, albo nowego rozwiązania, które wymagać będzie wersji setuptools sprzed tygodnia (i pozbawi was możliwości wsparcia starszych wersji Pythona, które najwyraźniej obchodzą jeszcze parę projektów).

No i rzecz jasna społeczność pythonowa podpowie: przypnij konkretną wersję zależności. Możecie sobie wyobrazić, jaka to będzie wielka frajda, kiedy jedne projekty zaczną arbitralnie przypinać wersję setuptools (np. do <77), żeby pozbyć się ostrzeżeń, a inne będą wymagać >=77 ze względu na nową konfigurację.

W takim razie… może mają państwo ochotę porozmawiać o systemie budowania flit? Albo o hatchling?

PS. A najśmieszniejsze w tym wszystkim to, że ostrzeżenie odnosi się do instrukcji, której jeszcze nawet nie zaktualizowano i która nadal twierdzi, że setuptools nie obsługują PEP 639.

https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106
https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files

So, now that the urgent fires have been put out for the time being, let's talk what other fun stuff #setuptools are doing these days.

For example, they have implemented PEP 639 recently (new license metadata). While doing that, they immediately deprecated their previous `license-field` field, giving people until 2026-02-18 to update their projects. The deprecation warnings also gives a helpful hint that you need setuptools 77 for the new field, which was released… a week ago.

So yeah, setuptools pretty much tells you that you need to choose between the old solution that means that all the versions of your package using it will stop building next February, or the new solution which means that your package will now require a week-old setuptools release (and effectively kill support for EOL Python versions, for which some projects apparently still care).

And of course the #Python community will tell you to solve the problem by pinning dependencies. And guess what happens when people put arbitrary pins (say, <77) to silence this deprecation warning, and other people have >=77 dependency, because they use the new variant.

So… would you like to talk about flit, perhaps? Or hatchling?

PS. The best joke is that they're pointing at a packaging guide that hasn't even been updated yet and still states that setuptools do not implement PEP 639.

https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/config/_apply_pyprojecttoml.py#L100-L106
https://web.archive.org/web/20250324035753/https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-files

> Nowy system budowania #PEP517 zbudowany na "dziesiątkach lat doświadczenia w ekosystemie i pracy z oprogramowaniem enterprise w skali światowej." [tłum. własne]

Sprawdza.

> Cykliczne zależność od samego siebie, przez co w ogóle tego nie da się zbudować.

> A new #PEP517 build system built on "decades of experience in the ecosystem and working on enterprise software at a global scale."

Looks inside.

> A cyclic dependency on itself, making bootstrap impossible.

Porównajmy backendy #PEP517 dla paczek napisanych w samym Pythonie:

#flit-core: 51 KiB archiwum źródłowe, bez zależności, instaluje się 0,05 s, ~150 KiB po zainstalowaniu, działa wszedzie
#UvBuild: 300 KiB archiwum, wymaga ~250 zależności crate (54 MiB pobierania, ~600 MiB w .cargo), buduje się 1 min 20 s (na 12-wątkowym procesorze), 4,2 MiB po zainstalowaniu, wspiera kilkanaście platform

I oczywiście, że flit-core ma szerszą funkcjonalność. Ale jestem przekonany, że gdzieś ktoś potrzebuje zaoszczędzić te kilka milisekund budowania paczek Pythona.

Let's compare #PEP517 backends for pure #Python packages:

#flit-core: 51 KiB sdist, no dependencies, 0.05 s to install, ~150 KiB after installing, works everywhere
#UvBuild: 300 KiB sdist, requires ~250 crates (54 MiB download, ~600 MiB .cargo directory), 1 min 20 s to install (on a 12-thread system), 4.2 MiB after installing, supports a dozen platforms

And yes, you guessed right, flit-core has more functionality. But I'm sure that there are performance-critical wheel building workflows that will benefit from these few milliseconds shaved off wheel building time.

Jakby ktoś nie śledził, to informuję, że #UvBuild jednak powstaje — i to straszna wiadomość dla wszystkich tych, których system nie jest wspierany przez #RustLang.

O co chodzi? Otóż, uv-build to system budowania #PEP517 dla projektów w "czystym" Pythonie (znaczy, bez kompilowanych rozszerzeń), który jest napisany w Ruście. Tak, dobrze wnioskujecie: budowanie niektórych paczek, które zawierają *wyłącznie pliki Pythona*, będzie teraz wymagało programu skompilowanego w Ruście.

Co to oznacza dla mnie? Czeka ma tłumaczenie ludziom, raz po raz, że wybrali "zły" backend, i ich paczka teraz nie jest przenośna, i niektórzy użytkownicy #Gentoo nie będą mogli już jej używać. Użeranie się z większą liczbą toksycznych ludzi, których po prostu nie obchodzą problemy innych, albo wprost wykorzystają sytuację, by kopnąć leżącego.

Oczywiście, zawsze jest nadzieja, że ktoś napisze wersję w Pythonie, której będzie można używać w miejsce standardowej. Ale nie będzie to nic przyjemnego, bo mówimy o projekcie "z szybkim tempem rozwoju" — który wprost odrzucił utrzymanie dodatkowej wersji w Pythonie, "ze względu na ograniczenia czasowe i, jak wspominano w wątku, fundamentalne różnice zachowania pomiędzy bibliotekami standardowymi Rusta I Pythona" [tłum. własne].

https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266

In case you aren't following the threads, #UvBuild is happening after all — and that's horrible news for anyone whose platform isn't supported by #RustLang.

What's that all about? Well, uv-build is a #PEP517 backend for pure #Python packages, that's written in Rust. Yes, that's what you think it means — building some *pure Python* packages will now require using a binary written in Rust now.

What does that mean for me? Having to repeatedly explain to people that their build backend decision is a problem for the portability of their package, and that some of #Gentoo users can't use it anymore. Having to deal even more with toxic people who are not interested in our problems, or who will even deliberately use this backend as an excuse to remove platform support.

Though, there is always some hope that someone will write a drop-in pure Python replacement for the backend, though it's going to be a pain since we're talking of following a project with high "rate of development" — a project that explicitly rejected maintaining a pure Python fallback "due to time constraints and, as mentioned by some, foundational differences in behavior between the Rust and Python standard libraries".

https://github.com/astral-sh/uv/issues/3957#issuecomment-2657825266

Today I'm posting on the company blog:

"""
In 2017, #PEP517 changed the #Python #packaging landscape forever. Prior to it, the setuptools build system held a de facto monopoly. If you were to publish a Python package on PyPI, you either used setuptools, extended it or had to create something reasonably compatible with it. And given how many different options setuptools provided, and how various users used different combinations of these options, you were likely to spend a lot of effort implementing what you believed to be necessary, and still learn that someone's workflow does not work.

PEP 517 enabled a ‘black box’ approach to building Python packages. A package needed only to name the backend it wished to use, and the backend implemented a few predefined functions to run the build process and create a source or binary distribution. This interface is well-defined and relatively simple. There are only two mandatory functions, and currently up to five optional — compared to 28 commands in setuptools (each with its own list of options).

Unsurprisingly, many new build systems were created. Some of them focused on pure Python packages, others on integration with other build systems such as CMake, Meson or Cargo. It is clear that you can now choose between many new build systems. But how popular are they today? In this post, I would like to explore that.
"""

https://labs.quansight.org/blog/pep-517-build-system-popularity

Okej, sprecyzujmy coś. #PEP621 to nie jest końcowy standard, który unifikuje systemy budowania #PEP517.

Tak, to dobry standard. Tak, dostarcza jednolitą specyfikację dla metadanych paczek. Jednakże, pomijając już opcję "dynamicznych metadanych", które zależą od implementacji, to PEP 621 nie specyfikuje, w jaki sposób mają tworzone być paczki źródłowe albo binarne — na przykład, skąd należy brać kod Pythona do paczki. To wszystko jest nadal wyborem konkretnej implementacji.

Dobra wiadomość: jeżeli paczka jest prosta jak konstrukcja cepa, i w miarę typowa, to najpewniej można w niej podmienić system budowania na inny zgodny z PEP 621, i będzie działać. Zła wiadomość: nie ma żadnej gwarancji. Rezultatem może być wszystko, od jakiś minimalnych różnic, do całkowicie dysfunkcyjnych paczek.

https://peps.python.org/pep-0621

Okay, let's get things clear. #PEP621 isn't the ultimate standard to unify #PEP517 build systems.

Yes, it's a good standard. Yes, it specifies a uniform format for specifying baseline package metadata. However, besides allowing for implementation-defined dynamic metadata, it does not specify anything related to how the source distributions and wheels are actually created — where to take Python packages from, for example. All these things are still implementation-defined.

Good news is, if your package has a trivial and common enough layout, then you can probably switch between different PEP 621-compliant build systems and things will just work. Bad news is, there's no guarantee of that. You may as well get anything from slight packaging differences to completely dysfunctional wheels and/or sdists.

https://peps.python.org/pep-0621

A tak na marginesie, zdaje się, że jedyny powód, dla którego #setuptools jeszcze istnieje, to dawanie ludziom wymówek, żeby tworzyli nowe backendy #PEP517. No, bo w porównaniu z setuptools to każdy wydaje się znacznie lepszy.

Also, I feel like the only purpose of #setuptools these days is to give people excuses to create new #PEP517 backends. Because obviously everything comes out better when compared to setuptools.

Zeloci: "Potrzebujemy backendu #PEP517 napisanego w #RustLang, bo wołanie do backendu w Pythonie jest zbyt powolne. A budowanie paczki to krytyczny pod względem wydajności element naszych działań!"

Ci sami zeloci: "Nie obchodzi nas stary sprzęt."

Ekonomiczny sprzęt z 2019: flit_core potrzebuje 0,2 s, żeby zbudować paczkę.

Zealots: "No, we must have a #PEP517 build backend in #RustLang, because calling out to #Python is too slow. Obviously the build step in our pipeline is performance critical!"

Same zealots: "We only care about the most recent hardware."

Value hardware from 2019: runs flit_core in 0.2 s.

@martin_kirch zwrócił moją uwagę na to, że projekt #uv dodaje swój własny backend do budowania #PEP517.

To przerażające! Proszę, rozważcie dołączenie do mnie w zgłaszaniu uwag.

uv to świetne narzędzie! Uwielbiam je, w roli menadżera pakietów. Ale nie jest szczególnie przenośne (i mam tu na myśli, że jest jeszcze gorzej niż z #RustLang ogółem — na przykład wciąż pracuję nad tym, żeby działało na PPC), i jest bardzo ciężkie. Za sprawą swojej popularności, wiele osób zdecyduje się użyć go do swoich projektów w Pythonie, i tym samym doda w czysto Pythonowych projektach zależność od niepythonowego, nieprzenośnego i ciężkiego backendu, którego tak naprawdę nie będą potrzebować.

Dla dystrybucji Linuksa to będzie koszmar. Wyobraźcie sobie, ile razy będę musiał zgłaszać problemy: "proszę, nie używajcie tego backendu, jest nieprzenośny i nie możemy już budować waszej paczki!". A skutkiem tego wszystkiego będzie mnóstwo frustracji, negatywności, złosliwości, a koniec końców łatania wszystkiego po naszej strony, żeby dało się to jeszcze zainstalować.

https://github.com/astral-sh/uv/issues/3957

As @martin_kirch pointed out, the #uv project is working on adding its own #PEP517 builder.

This is just terrifying! Please consider joining me in raising concerns about it.

uv is a great tool! I do love it as a #Python package manager. But it is not very portable (even less portable than #RustLang in general, e.g. I'm still working on getting it fixed for PPC), and it is very heavy. And its popularity means that a lot of pure Python packages will now have a dependency on this non-pure, non-portable, heavy build backend that they don't really need.

This is going to be a true nightmare for downstreams. Just imagine me filing bugs, repeatedly asking people "please don't use this build backend, we can't build your package anymore because uv is non-portable!" And this will surely result in a lot of frustration, negativity, knee-jerk reactions and downstream patching just to keep things installable.

https://github.com/astral-sh/uv/issues/3957

New on blog: "Poetry(-core), or the ultimate footgun"

"""
I've been complaining about the Poetry project a lot, in particular about its use (or more precisely, the use of poetry-core) as a build system. In fact, it pretty much became a synonym of a footgun for me — and whenever I'm about to package some project using poetry-core, or switching to it, I've learned to expect some predictable mistake. I suppose the time has come to note all these pitfalls in a single blog post.
"""

https://blogs.gentoo.org/mgorny/2024/12/20/poetry-core-or-the-ultimate-footgun/