Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.

#Python

Some fun facts about #Python limited API / stable ABI.

1. #CPython supports "limited API". When you use it, you get extensions that are compatible with the specified CPython version and versions newer than that. To indicate this compatibility, such extensions use `.abi3.so` suffix (or equivalent) rather than the usual `.cpython-313-x86_64-linux-gnu.so` or alike.

2. The actual support is split between CPython itself and #PEP517 build systems. For example, if you use #setuptools and specify `py_limited_api=` argument to the extension, setuptools will pass appropriate C compiler flags and swap extension suffix. There's a similar support in #meson, and probably other build systems.

3. Except that CPython freethreading builds don't support stable ABI right now, so building with "limited API" triggers an explicit error from the headers. Setuptools have opted for building explicit about this: it emits an error if you try to use `py_limited_api` on a freethreading interpreter. Meson currently just gives the compile error. This implies that package authors need to actively special-case freethreading builds and enable "limited API" conditionally.

4. A some future versions of CPython will support "limited API" in freethreading builds. I haven't been following the discussions closely, but I suspect that it will only be possible when you target that version or newer. So I guess people will need to be building two stable ABI wheels for a time — one targeting older Python versions, and one targeting newer versions plus freethreading. On top of that, all these projects will need to update their "no 'limited API' on freethreading" conditions.

5. And then there's #PyPy. PyPy does not feature a stable ABI, but it allows you to build extensions using "limited API". So setuptools and meson just detect that there is no `.abi3.so` on PyPy, and use regular suffix for the extensions built with "limited API".

Dni bez przypadkowego projektu na #setuptools migrującego na `pyproject.toml`, usuwającego plik `MANIFEST.in` i wskutek tego psującego archiwum ze źródłami: [0].

Days since a random #setuptools project migrated to `pyproject.toml`, removed `MANIFEST.in` and broke source distribution in the process: [0].

#Gentoo

Nieudany 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 + #setuptools.

2. Inny projekt wydał nową wersję z popsutymi testami. Na głównej gałęzi działają — widać nikomu nie zależało, żeby przetestować gałąź z wydaniem.

3. Właśnie odkryłem, że kilka paczek na nowo zaczęło używać przestrzeni nazw pkg_resources — a byłem przekonany, że pozbyliśmy się tego gówna lata temu! No i oczywiście, że #Google. A że teraz pkg_resources jest oficjalnie przestarzałe, rzuca ostrzeżeniami, które psują testy w innych paczkach.

A z rzeczy pozytywnych: w redis-py sypie mi się test_lolwut.

#Python

A 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.

Paczka 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

A #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

co jest gorsze niż #setuptools? Paczka, która przechodzi na #Hatchling, ale wewnętrznie woła w paskudny sposób setuptools, żeby zbudować rozszerzenie w C — i w ten sposób ignoruje budowanie poza katalogiem źródłowym.

#Gentoo #PEP517

What's worse than #setuptools? A package switching over to #Hatchling, then internally calling setuptools in an awful way to build a C extension, completely bypassing out-of-tree builds.

#Gentoo #PEP517

Uwaga: #setuptools ogłosiło, że `setup.py install` wyleci 2025-10-31.

https://setuptools.pypa.io/en/latest/history.html#v80-1-0

#Python #PEP517

PSA: #setuptools added a deadline for `setup.py install` removal: 2025-10-31.

https://setuptools.pypa.io/en/latest/history.html#v80-1-0

#Python #PEP517 #packaging

#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")

https://github.com/pypa/setuptools/issues/4937

#Python

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")

https://github.com/pypa/setuptools/issues/4937

#Python #packaging

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

#PEP517 #Python

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

#packaging #PEP517

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.

https://discuss.python.org/t/installing-headers-from-wheel-should-the-directory-be-normalized-or-not/85990

#Python

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.

https://discuss.python.org/t/installing-headers-from-wheel-should-the-directory-be-normalized-or-not/85990

#packaging #Python

setuptools team learned yesterday that "Postel's Law" is more like the law of gravity than software architecture guidance.

#python #setuptools

#python #setuptools