#setuptools jest super: jeżeli macie gdzieś w źródłach dowiązanie symboliczne do katalogu, to setuptools przypadkowo zdecyduje, by do dystrybucji źródłowej albo dodać oryginalny katalog, albo przenieść go w miejsce dowiązania, ignorując oryginalną lokalizację.
Więc jeżeli macie:
a/a
a/b
a/c
b -> a
to przypadkowo dostaniecie albo:
a/a a/b a/c (bez "b")
albo:
b/a b/b b/c (bez "a")
So #setuptools fun: if your source tree contains a symbolic link to a directory, setuptools may randomly either include the original directory in the source distribution, or move it where the symlink was, disregarding the original location.
So if you have:
a/a
a/b
a/c
b -> a
you'll randomly end up with either:
a/a a/b a/c (and no "b")
or:
b/a b/b b/c (and no "a")
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
Na kanwie mema z dominem:
1. #setuptools zaczyna normalizować nazwy plików archiw binarych, w zgodzie z PEP 491.
…
n. #PyCXX nagle zaczyna instalować nagłówki w `/usr/include/python*/cxx` zamiast `CXX` (wielkimi literami).
Co ciekawe, problem dotyka zarówno paczek #pip i #installer. Krótko mówiąc, ścieżka instalacji nagłówków używa "nazwy dystrybucji", i wygląda na to, że w obydwu przypadkach nazwa ta pobierana jest z nazwy pliku. Nie wiem, czy to błąd, ale myślę, że zgłoszę, na wszelki wypadek. W installerze nawet jest notatka, wskazująca, że autor nie był pewny, czy używać oryginalnej, czy znormalizowanej nazwy.
Domino meme:
1. #setuptools starting to finally normalize wheel filenames per PEP 491.
…
n. #PyCXX suddenly installing header files into `/usr/include/python*/cxx` instead of uppercase `CXX`.
Funny enough, it affects both #pip and #installer. Long story short, the include install path uses "distribution name", and in both cases the distribution name is apparently taken from the filename. Not sure if this is a bug or a feature, but I guess i'll file bugs. Installer even has a TODO item to determine whether they should be using original or normalized name.
setuptools team learned yesterday that "Postel's Law" is more like the law of gravity than software architecture guidance.
(Note: credit where credit is absolutely do: setuptools team stepped up and embraced the issue, putting together a very quick rollback to unbreak everybody and move the deprecation deadline further out. That was extremely responsible.)
"But it's not setuptools fault that other projects didn't respond to a deprecation warning from 2021..."
There's a concept of "Responsibility without fault." There's a pretty famous blog post, which I regrettably cannot lay hands upon, where an ex-Microsoft engineer talks about how when they upgraded Windows, testing showed they broke Photoshop. Drilling down revealed that they had changed the details of some C++-implemented APIs that resulted in a binary change to the API buffers, but that should have been irrelevant because the pattern to use those APIs was to request a buffer from the OS and then fill it in.
Adobe had optimized some cycles away by caching their own pre-filled copies of those buffers, which, of course, broke when the binary layout of the buffer changed.
Microsoft's solution? They reimplemented those buffers in C so they could maintain binary compatibility and not break Photoshop. Because if Photoshop broke in a new version of the OS, end-users wouldn't blame Adobe, they'd blame the thing that changed, and Microsoft is in the business of selling operating systems.
It's not about fault, really. It's about "as a software project, do you want to be the one people use or the one people route around?" And that's more of a social network challenge than an engineering challenge.
(This also goes to the question "How could they possibly have known they'd break other projects?" Well... Microsoft maintains a list of must-use software they test new OS versions against. If you're as big as setuptools, you may be big enough to maintain such a list for testing purposes).
I often laud that the Python ecosystem has the advantage over the Rails ecosystem of "adults in the room."
I have to say, watching setuptools break a significant number of builds today because they turned a deprecation into an exception, tickling a known-and-repeatedly-reported issue with poetry that it relies always on the most recent setuptools, has damaged my calm on this topic.
On the plus side, everyone involved seems to be converging on a solution.
Yup, https://build.opensuse.org/project/show/devel:languages:python is now completely on fire because of #setuptools. Somebody should really tell them something about API stability.
https://pol.social/@mgorny/114137230306646886
I stało się! Tak, #setuptools dosłownie wysadzili w powietrzę kupę paczek Pythona (tak popularnych jak requests), bo najwyraźniej był to dobry sposób na rozwiązanie problemu z ich własnymi testami. Jasne, już od lat setuptools ostrzegało, że taki zapis konfiguracji jest przestarzały. Ale jak już mówiłem wiele razy, *nikt* nie widzi tych ostrzeżeń.
No chyba że ktoś używa #Gentoo, bo mamy jedyny menadżer pakietów, który przechwytuje i w sposób zauważalny powtarza ostrzeżenia o przestarzałych funkcjach w setuptools. Ale my nie mamy czasu poprawiać ludziom projektów, bo cały czas musimy walczyć z pożarami, które inne projekty cały czas nam podkładają.
https://social.treehouse.systems/@mgorny/114137227235533135
Yes, they did it. #setuptools literally made lots of #Python packages (such as requests) explode, apparently in order to resolve a problem with their own test suite. Sure, that stuff has been deprecated for a long time. But as I've said multiple times, *nobody* sees these deprecation warnings.
Well, unless they run #Gentoo, because we have literally the only Python package installer out there that catches and repeats setuptools deprecation warnings verbosely. But we don't have time to fix deprecations in upstream packages while upstreams are making sure to set up fires all over the place, all the time.
A pamiętacie, jak myśleliście, że można ignorować te wszystkie ostrzeżenia generowane, kiedy #setuptools przypadkowo zmieniał nazwy pierdół, bo przecież nigdy nie usuną wstecznej zgodności?
Remember when you thought it's fine to ignore all these deprecation warnings about #setuptools randomly renaming stuff, because they're never going to remove the backwards compatiblity?
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.
I suppose I could use my experience to give some #PEP517 build system recommendations.
For pure #Python packages:
1. #flit_core (https://pypi.org/project/flit-core/) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).
2. #hatchling (https://pypi.org/project/hatchling/) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in #Gentoo).
For Python packages with C extensions: #meson-python (https://pypi.org/project/meson-python/) — which combines the power and correctness of meson build system with good very Python integration.
For Python packages with Rust extensions: #maturin (https://pypi.org/project/maturin/) — which is simply a good builder for precisely that kind of packages.
Now, I strongly discourage:
A. #setuptools — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.
B. #poetry-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).
C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.
W sumie mogę dać parę rekomendacji systemów budowania #PEP517.
Dla paczek w samym Pythonie:
1. #flit_core (https://pypi.org/project/flit-core/) — leciutki, prosty, i nie ma zależności (za wyjątkiem włączonego tomli dla starszych wersji Pythona).
2. #hatchling (https://pypi.org/project/hatchling/) — popularny, duża funkcjonalność, ale ma sporo włączonych zależności, a testy są zależne od reszty projektu hatch (przez co w #Gentoo się mocno z tym męczymy).
Dla paczek z rozszerzeniami w C: #meson-python (https://pypi.org/project/meson-python/) — połączenie szerokiej funkcjonalności i poprawności mesona z dobrą integracją z Pythonem.
Dla paczek z rozserzeniami w Ruście: #maturin (https://pypi.org/project/maturin/) — po prostu dobry system budowania dla tego typu paczek.
Stanowczo odradzam:
A. #setuptools — mnóstwo włączonych do projektu zależności, które wynajdują koło na nowo (które można zastąpić zewnętrznymi, które z kolei mają cykliczną zależność od setuptools), ciągłe wycofywanie starej funkcjonalności (której wciąż używa mnóstwo paczek), wiele nierozwiązanych problemów (np. równoległe budowanie plików C jest częściowo popsute), sporo długu technicznego, a jeżeli to nie wystarcza, to do tego strasznie powolny.
B. #poetry-core — trudny do poprawnego użycia system budowania, w którym bardzo łatwo popełnić błąd (a zgłaszałem już wiele pomyłek, które ludzie robili migrując swoje projekty).
C. Praktycznie każdy inny system budowania — pisanie nowych backendów stało się banalne, więc każdy musi mieć swój. Do tego często mają mnóstwo zależności, które wynajdują koło na nowo (jak już ktoś chce wynaleźć własny system budowania, to może równie dobrze pójść na całość i wynaleźć wszystko), brak doświadczenia i tym samym powtarzają te same błędy przeszłości. A jeżeli tego nie wystarczy, to dodawanie pod nie paczek do dystrybucji to tylko kupa roboty bez żadnej realnej korzyści.
