101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

475
active users

#pypy

2 posts2 participants0 posts today

Jakiś czas temu, zainspirowany #Fedorą, wyodrębniłem paczki .whl z Pythonowego ensurepip w #Gentoo (właśnie sprawdziłem — "jakiś czas" to 3 lata). Umożliwiło to nam aktualizowanie ich razem z paczkami pip i setuptools, dzięki czemu nowe środowiska wirtualne otrzymują najnowszą dostępną wersję, a nie tę, którą włączono w dane wydanie CPythona.

Myślałem wówczas, by budować je z naszych systemowych paczek, ale już wówczas usuwaliśmy zagnieżdżone zależności, więc otrzymalibyśmy niepełne paczki. Zamiast tego po prostu zgarnialiśmy gotowe paczki z PyPI. A dlaczego nie budować ich na nowo ze źródeł? Pomijając fakt, że wydawało się to zbędne (wszak paczki na PyPI nie zawierają żadnego skompilowanego kodu), nie mieliśmy do tego dobrej infrastruktury w eclass.

Za inspiracją @hroncok, dziś przygotowałem nowe wersje paczek ensurepip, które budują wszystko ze źródeł. Co się zmieniło, i dlaczego warto dziś budować ze źródeł? Po pierwsze, nasz kod budowania PEP517 dorobił się możliwości wydobycia poprzednich paczek .whl. Po drugie, skoro usuwamy zagnieżdżone zależności z pipa i setuptools, to właściwie testujemy inny kod niż ten, który trafia do ensurepip — a myślę, że miałoby sens testowanie obydwu wariantów. Po trzecie, budowanie ze źródeł ułatwi nakładanie łatek, a w szczególności umożliwi użytkownikom łatwe dodawanie lokalnych łatek.

A skoro już się za to wziąłem, to przy okazji zaktualizowałem stan testów we wszystkich trzech paczkach (pip, setuptools i wheel — tego ostatniego potrzebujemy ze względu na testy). No i oczywiście, że trafiłem na padające testy w wersjach z zagnieżdżonymi zależnościami, i przypadkiem odkryłem błąd w #PyPy.

github.com/gentoo/gentoo/pull/ (tak, nadal tam jesteśmy)
github.com/pypy/pypy/issues/53

CC @gentoo/python

 pip
 setuptools
 wheel

Goals:

Make it easier to patch stuff.
Run tests against vendored dependencies in addition to the debundled testing (which usually implies skipping some ...
GitHubdev-python/ensurepip-*: Switch to building from source by mgorny · Pull Request #42882 · gentoo/gentooBy mgorny

A while ago, I've followed the example given by #Fedora and unbundled ensurepip wheels from #Python in #Gentoo (just checked — "a while ago" was 3 years ago). This had the important advantage that it enabled us to update these wheels along with the actual pip and setuptools packages, meaning new virtual environments would get fresh versions rather than whatever CPython happened to bundle at the time of release.

I had considered using our system packages to prepare these wheels, but since we were already unbundling dependencies back then, that couldn't work. So I just went with fetching upstream wheels from PyPI. Why not build them from source instead? Well, besides feeling unnecessary (it's not like the PyPI wheels are actually binary packages), we probably didn't have the right kind of eclass support for that at the time.

Inspired by @hroncok, today I've tried preparing new revisions of ensurepip packages that actually do build everything from source. So what changed, and why should building from source matter now? Firstly, as part of the wheel reuse patches, we do have a reasonably clean architecture to grab the wheels created as part of the PEP517 build. Secondly, since we're unbundling dependencies from pip and setuptools, we're effectively testing different packages than these installed as ensurepip wheels — and so it would be meaningful to test both variants. Thirdly, building from source is going to make patching easier, and at the very least enable user patching.

While at it, I've refreshed the test suite runs in all three regular packages (pip, setuptools and wheel — we need an "ensurepip" wheel for the last because of test suites). And of course, I hit some test failures in testing the versions with bundled dependencies, and I've discovered a random bug in #PyPy.

github.com/gentoo/gentoo/pull/ (yes, we haven't moved yet)
github.com/pypy/pypy/issues/53

CC @gentoo/python

 pip
 setuptools
 wheel

Goals:

Make it easier to patch stuff.
Run tests against vendored dependencies in addition to the debundled testing (which usually implies skipping some ...
GitHubdev-python/ensurepip-*: Switch to building from source by mgorny · Pull Request #42882 · gentoo/gentooBy mgorny

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.

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

W oczekiwaniu jutrzejszej Wielkiej Zmiany, przebudowuję mój kontener roboczy #Gentoo, wyłączając wsparcie Pythona 3.10 oraz #PyPy 3.10. 1158 paczek do przebudowania — i długa lista konfliktów. Tyle że nie wiem, czy te konflikty to "nie przebuduję tych paczek", czy tylko "poradziłem sobie z nimi".

Przypomnienie: 2025-05-01, #Gentoo przechodzi na Pythona 3.13, jako domyślną wersję.

Usuwamy również wsparcie budowania paczek dla Pythona 3.10 i #PyPy 3.10. W odróżnieniu od wcześniejszych migracji, przejście na PyPy 3.11 wymaga zmiany flag PYTHON_TARGETS.

Spodziewamy się również, że wersja beta CPythona 3.14 wyjdzie jakoś w połowie maja, i od tego momentu będziemy stopniowo dodawać wsparcie do paczek, w miarę dostępnego czasu.

public-inbox.gentoo.org/gentoo
gentoo.org/support/news-items/

public-inbox.gentoo.org[gentoo-dev] [Python] The big plans for May: Python 3.13 by default, Python 3.10 + PyPy 3.10 gone, Python 3.14 incoming

PSA: reminder that on 2025-05-01, #Gentoo is switching the default to #Python 3.13.

We are also removing the support for Python 3.10 and #PyPy 3.10 targets. Unlike the previous times, the upgrade to PyPy 3.11 now requires switching target flags.

We also do expect CPython 3.14 betas to land mid-May, and we will start adding relevant targets soon afterwards, as time permits.

public-inbox.gentoo.org/gentoo
gentoo.org/support/news-items/

public-inbox.gentoo.org[gentoo-dev] [Python] The big plans for May: Python 3.13 by default, Python 3.10 + PyPy 3.10 gone, Python 3.14 incoming

Dear @ThePSF ...

having been engaged with #Python through co-creating #pytest #pypy, giving talks and trainings i appreciate that the PSF has long been a champion of diversity and inclusion! Are you aware that these days many non-USians are canceling their US travels? The German foreign ministry warns about travel to the US if you are pregnant or don't have your passport carrying a birth gender marker, then this: kpbs.org/news/border-immigrati

Maybe better update the #Pycon webpage accordingly?

Parę liczb: z 823 paczek ze wsparciem #PyPy 3.x w #Gentoo, 712 już doczekało się wsparcia PyPy 3.11. Zostało parę istotnych problemów do rozwiązania (m.in. IPython, z wieszającym się IPyParallel), i trochę paczek, które po prostu nie mają testów (więc jeszcze się im nie przyglądałem).

Co ciekawe, najczęstsze problemy z testami na PyPy 3.11 to:

• niestabilne testy (czyli trzeba uruchomić je jeszcze raz, najlepiej bez 70 innych paczek testowanych jednocześnie)
• istniejące, niezależne od wersji Pythona regresje (potwierdzone przez testowanie na CPythonie 3.11)
• istniejące problemy na PyPy 3.10 (wystarczy skopiować pomijane testy)
• nieistotne różnice, typu trochę inne komunikaty w wyjątkach

Poważne problemy to rzadkość, i zazwyczaj szybko są rozwiązywane (albo obchodzone przeze mnie). Naprawdę udane wydane! Wielkie podziękowania dla wszystkich, którzy pracują nad tematem!

Some fun numbers: out of 823 packages featuring #PyPy 3.x support in #Gentoo, 712 have already been ported to PyPy 3.11. There are a few significant blockers left (notably #IPython, with hanging IPyParallel), and a fair number of packages that simply don't have tests (so I haven't looked at them yet).

Interesting enough, the most common test failures seen while porting to PyPy 3.11 are:

• flaky tests (i.e. just need to rerun, especially without parallelization of testing 70 packages simultaneously)
• existing, irrelevant test regressions (i.e. confirmed by testing with CPython 3.11)
• existing test problems with PyPy3.10 (i.e. need to copy deselects)
• some minor differences, such as slightly different exception messages

Serious issues are really rare, and they are often fixed (or worked around by me) promptly. Really great release! Thanks to everyone involved!

A cóż ja mogę teraz robić, w piątkowy wieczór?

Oczywiście, że wysyłam zgłoszenia do przypadkowych projektów #Python / #RustLang, prosząc o aktualizację wersji #PyO3 i nowe wydanie, po to, by móc wprowadzić wsparcie #PyPy 3.11 w #Gentoo. Bo, rzecz jasna, prawidłowy sposób rozwoju współczesnych paczek Pythona to przypadkowo przepisywanie ich fragmentów w Ruście, a potem ignorowanie konieczności aktualizowania zależności przez pół roku albo dłużej.

Tak, mówię o tych wszystkich paczkach, które w ogóle jeszcze nie wspierają PyO3 0.23.x.

A potem jeszcze przyjdą i powiedzą, że powinniśmy zostawić temat zależności i bezpieczeństwa autorom projektów.

What could I be doing right now, on a Friday evening?

Of course filing bugs on random #Python / #RustLang packages requesting a #PyO3 version update and a new release, to support #PyPy 3.11 in #Gentoo. Because obviously the right way to maintain modern Python packages is to rewrite random parts of them in Rust, then neglect updating their dependencies for half a year or more.

Yes, I'm talking about all the packages that don't even support PyO3 0.23.x yet.

And then they'll come and say that we should leave dependency management and security to upstreams.

Dobra wiadomość: jest łatka dla #PyO3 dla wsparcia #PyPy 3.11, więc ruszamy z aktualizacjami w #Gentoo do przodu.

Złe wiadomości:

1. Mówimy o #RustLang, więc każdą paczkę trzeba łatać z osobna.
2. Nie chcemy trzymać dziesiątek kopii tej samej łatki, więc chcemy ją ciągnąć z sieci. Niestety, nie możemy użyć oryginalnej kopii, bo modyfikuje pliki, których nie znajdziemy w archiwum crate.
3. No więc trzymamy własną kopię tej łatki, ograniczoną do dostępnych plików. Niestety, pasuje tylko do wersji 0.23.4, a że mnóstwo paczek Pythona używa 0.23.3, to mamy sporo aktualizowania. Ale przynajmniej w większości przypadków wystarczy podmienić cyferki na liście `CRATES`, i wykasować `Cargo.lock`.
4. …no chyba że dana paczka akurat wymusza dokładnie 0.23.3, albo używa 0.22.x bądź starszej wersji. Wtedy bez łatania `Cargo.toml` się nie obędzie.

No ale idziemy do przodu. Tyle że warto jeszcze wspomnieć, że z paczek Pythona robi się coraz większy bajzel cyklicznych zależności, ale to już inna bajka.

Good news is, there's an upstream patch for #PyO3 to support #PyPy 3.11, so the #Gentoo updates are progressing.

Bad news:

1. Since it's #RustLang, we need to patch every single package separately.
2. To avoid keeping a dozen copies of the same patch, we'd like to fetch it. Unfortunately, we can't use upstream pull request directly since it edits a bunch of files that aren't in the crate.
3. Ok, so we host a modified patch and we're good here. Unfortunately, the patch doesn't apply cleanly to the previous minor release (0.23.3), so we need to manually update PyO3 in a lot of #Python packages. Good news is, that's usually updating our `CRATES` list and removing `Cargo.lock`.
4. …except for these packages that pin exactly to 0.23.3, or are still on 0.22.x or earlier. Then we also need to patch `Cargo.toml`.

But yeah, things are going forward. And then of course Python packages are becoming an increasingly convoluted mess of cyclic dependencies, but that's another story.

Właśnie dodałem wybór wersji Pythona pypy3_11 do #Gentoo!

Oznacza to, że:

• Wariant "pypy3" nie będzie już odnosił się do nowszych gałęzi #PyPy, i zamiast tego do momentu usunięcia będzie oznaczać "PyPy3.10".
• Nowe gałęzie PyPy otrzymywać będą własne warianty "pypy3_x".
• W trakcie okresów przejściowych, będzie można aktywować dwa warianty jednocześnie, co powinno ułatwić aktualizacje.
• Nowe warianty PyPy będą odwoływać się bezpośrednio do binarek "pypy3.x", a nie przez dowiązanie symboliczne "pypy3".
• Po wyłączeniu wariantu "pypy3", tym samym będzie można ustawić "pypy3", bo odwoływało się do dowolnej wersji. Najpewniej przestawimy je na użycie python-exec, tak jak teraz działa "python3".

To powiedziawszy, dopiero zacząłem testować paczki na PyPy3.11, więc potrwa chwilę, zanim będzie można w 100% przełączyć system. Zacząłem też dyskusję na temat momentu usunięcia wariantów #Python 3.10:

archives.gentoo.org/gentoo-dev

archives.gentoo.org[gentoo-dev] [RFC] The future of Python 3.10 target