#pep517 — Public Fediverse posts

Dziś ktoś pytał w temacie walki z ostrzeżeniami o "przestarzałej" funkcjonalności w #setuptools (w #Gentoo zbieramy je i wypisujemy ponownie, więc ludzie faktycznie mogą je zauważyć). Myślę, że moją najlepszą podpowiedzią było: użyj innego systemu budowania.

#Python #PEP517

Someone asked about fixing #setuptools deprecation warnings today (#Gentoo collects and reprints them, so people actually notice). I think my best hint is: use another build system.

#Python #PEP517

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

New 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 🤦.

https://github.com/python-poetry/poetry/issues/10083

#Gentoo #PEP517

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

Zapomniałem się pochwalić: w systemie budowania #hatchling jest błąd, który sprawia, że przypadkowo instalowany jest niewłaściwy zestaw plików, jeżeli buduje się w katalogu, do którego ścieżka przypadkiem pokrywa się z jednym z wpisów gitignore.

Na przykład, jak projekt ignoruje "var/", a my budujemy paczkę w /var/tmp…

https://github.com/pypa/hatch/issues/1964

#Gentoo #PEP517

Oh, I forgot to post that: there's a bug in #hatchling that makes it randomly install the wrong files if you're building in a path that just happens to match one of the gitignore entries.

Say, if upstream ignores "var/", and you happen to be building inside /var/tmp…

https://github.com/pypa/hatch/issues/1964

#Gentoo #PEP517

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.

#Python #RustLang #uv

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.

#Python #RustLang #uv

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.

#Python #RustLang #uv

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.

#Python #RustLang #uv

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.

#Python #RustLang #uv

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.

#RustLang #uv

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.

#RustLang #uv

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.

#RustLang #uv

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.

#RustLang #uv

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.

#RustLang #uv

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/

#Gentoo #Python #PEP517 #PythonPoetry

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.

#Python

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.

Jakiś czas temu dwa systemy budowania #PEP517 dorobiły się funkcji weryfikacji klasyfikatorów #PyPI ("trove classifiers"). Na pierwszy rzut oka, ma to sens: wszak warto poinformować autorów paczek od razu, jeżeli gdzieś popełniono błąd i paczka zostanie odrzucona. Problem stanowi jednak fakt, że ta weryfikacja dotyczy również budowania paczek lokalnie — a więc użytkowników #Gentoo.

Funkcję zbudowano w oparciu o paczkę "trove-classifiers". Ilekroć nowy klasyfikator dodawany jest do PyPI, wydawana jest nowa wersja tej paczki. Jeżeli używamy narzędzi takich jak `build` czy `pip`, każdorazowo z sieci instalowana jest najnowsza wersja tej paczki. Na Gentoo natomiast, o ile nie wymusimy tego zależnościami, użytkownik może mieć przestarzałą. Jeżeli wówczas spróbuje zainstalować paczkę Pythona, która używa nowszych klasyfikatorów, otrzyma mylący błąd o błędnym klasyfikatorze. Mylący, bowiem: 1) wbrew komunikatowi, klasyfikator jest poprawny; 2) nawet gdyby nie był, to problem nas w ogóle nie dotyczy.

Dlatego też wystąpiliśmy z prośbą o możliwości wyłączenia tej funkcji. Choć zajęło to trochę czasu, opiekun paczki #Hatchling wykazał zrozumienie dla naszego problemu i zaakceptował moją łatkę. Z kolei opiekun #setuptools… no cóż, podjął się długiej i bezowocnej debaty, która poskutkowała zignorowaniem trywialnego rozwiązania głównego problemu ("niepotrzebna komplikacja"). Zamiast tego, zaproponowano nam rozwiązanie dosyć wątpliwe — całkowite wyłączenie weryfikacji poprawności pliku `pyproject.toml`. Rozwiązanie nieakceptowalne z dwóch powodów: 1) dlatego, że setuptools polega na tej weryfikacji (a więc przy błędach w pliku moglibyśmy dostać zepsutą instalację zamiast błędu); 2) dlatego, że przy budowaniu każdej paczki rzuca paskudnym ostrzeżeniem. W praktyce więc znęcalibyśmy się nad użytkownikami Gentoo, zarzucając ich fałszywymi ostrzeżeniami, i niektórzy z nich prawdopodobnie niepotrzebnie zgłaszaliby problem autorom właściwej paczki.

Nie używajcie setuptools.

https://github.com/pypa/hatch/issues/1368
https://github.com/pypa/setuptools/issues/4459

#Python

Some time ago two #PEP517 build systems introduced #PyPI trove classifier verification. At a first glance, it makes sense. After all, if you made a mistake somewhere, you'd rather know early than when you try to upload the package. The problem is, that the verification fires for people building packages locally too — including #Gentoo users.

Now, this function was based on the #Python "trove-classifiers" package. Whenever a new classifier is introduced, a new release of the package is made. When you're building a package using tools such as `build` or `pip` (isolated build), the newest version of this package is being installed from the Internet. On the other, a Gentoo user may have an old version, unless we enforce an upgrade via package dependencies. Then building packages that use newer classifiers will fail, and with a confusing message too. Confusing because: 1) contrary to the message, the classifier is valid; and 2) even if it weren't, it doesn't affect us in any way.

And so we asked for an ability to disable this. While it took some time, the #Hatchling showed understanding and eventually merged my patch. On the other hand, the #setuptools maintainer… well, started a long and tedious debate that resulted in ignoring the trivial solution to the actual problem (as "unnecessary complexity"). Instead, we were given another option: we could entirely disable `pyproject.toml` validation. It's not really acceptable, for two reasons: 1) because setuptools actually rely on this validation (so removing it could result in broken package installs instead of an error, if the file is not valid), and 2) because it produces an awful warning on every package build. So we'd end up bullying Gentoo users with false warnings, and some of them would probably end up filing invalid bugs to various upstreams.

The bottom line is: don't use setuptools.

https://github.com/pypa/hatch/issues/1368
https://github.com/pypa/setuptools/issues/4459

@mgorny Three of those are by me, sorry you think it look like shit. (I have since reverted some to be more concise: https://github.com/termcolor/termcolor/commit/09ca9cc88b7e31623b8c561aa1fe87383ddd8f72)

I also prefer the original, but #TOML isn't the prettiest and it's much more valuable and maintainable for me to have things consistent and autoformatted than to re-arrange by hand.

Have you tried making suggestions with the formatter? Do you know another formatter that I could use that is better? Is there a #PEP517 / #PyProjectToml style guide?

#Python

Kiedy przypadkowe projekty używające narzędzia do formatowania plików #PyProjectToml, od pewnej osoby z opiniami, i nagle pliki `pyproject.toml` tych wszystkich projektów zaczynają wyglądać, jakby ktoś je wysrał, bo rzeczona osoba zmieniła zdanie, i stwierdziła, że klucze z kropkami dla tabelek #TOML nie są fajne, i lepiej wszystkie wartości w upchnąć w nadrzędnych tabelach. Czy muszę dodawać, że to zupełnie inaczej, niż stosuje się w przykładach dla każdego jednego systemu budowania #PEP517?

Kilka przykładów projektów, w których to nastąpiło (często za sprawą pre-commit):

https://github.com/pypa/virtualenv/commit/7cbed79924b6b6d953ca9ecf40de23a7d3486f57#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/django-commons/django-debug-toolbar/commit/2990290d43618df5eab357f2a36363186d51d5a8#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/pytest-dev/pytest/commit/5d5c9dc85850f64621190e62bd20d4b190bdbdb6#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/prettytable/prettytable/commit/88bebdac122b82af255656513080bdd2c90098d9#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/python-humanize/humanize/commit/aa3a94e011a795a0551717c5a78a566bc2672390#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/termcolor/termcolor/commit/9e35c66ab7ad48a33d5c2829dbee02382aa716e5#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

#Gentoo #Python

When random projects use a certain #PyProjectToml formatter from a certain opinionated upstream, and now all projects suddenly have their `pyproject.toml` files rewritten to look like shit, because opinionated upstream changed their mind, and decided that dotted #TOML table keys are no cool and it's better to inline everything into top-level tables. Which — I should point out — is against the style used in examples of every single #PEP517 build system out there.

Just a few examples where it happened (often via pre-commit hooks):

https://github.com/pypa/virtualenv/commit/7cbed79924b6b6d953ca9ecf40de23a7d3486f57#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/django-commons/django-debug-toolbar/commit/2990290d43618df5eab357f2a36363186d51d5a8#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/pytest-dev/pytest/commit/5d5c9dc85850f64621190e62bd20d4b190bdbdb6#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/prettytable/prettytable/commit/88bebdac122b82af255656513080bdd2c90098d9#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/python-humanize/humanize/commit/aa3a94e011a795a0551717c5a78a566bc2672390#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711
https://github.com/termcolor/termcolor/commit/9e35c66ab7ad48a33d5c2829dbee02382aa716e5#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

#Gentoo #Python

Jak uprzejmie zasugerować komuś, że stworzony przezeń system budowania #PEP517 to typowe #NIH? Można tak:

https://github.com/repo-helper/whey/issues/52

No i tak, kompletne NIH, wymaga ConsoleKit (serio?!), wymaga kilku innych paczek NIH tego autora, i ma stale bota. No i praktycznie rzecz biorąc, jedynie autor używa tego wynalazku.

Więc dlaczego się tym przejmuję? Bo ten sam autor stworzył wtyczkę dla systemu budowania #Hatchling, hatch-requirements-txt, i ta wtyczka zależy od paczek, które używają wheya. No więc tak, mamy tu kolejny przykład osoby, która zrobiła jedną potencjalnie użyteczną paczkę (ja jej za taką nie uważam, ale inne projekty używają), i za jej pomocą wymusza na innych całą resztę swoich NIH-projektów.

#Gentoo #Python

How to politely point out that somebody's #PEP517 build system is utter #NIH? Here's one whey… err, way:

https://github.com/repo-helper/whey/issues/52

And yes, it's complete NIH, with a dependency on ConsoleKit (seriously?!), a bunch of NIH packages, and a stale bot. On top of that, it's practically used only by its author.

So why do I care? Because the same person also made hatch-requirements-txt #Hatchling plugin, and said plugin depends on NIH packages (of course it does) using whey. So yeah, another case of making one potentially useful package (actually, I don't consider it useful, but random projects depend on it now) and using it to force your NIH projects on everyone.

#Gentoo #Python

#PythonPoetry znów uderza. Nie mam już siły tego komentować.

https://github.com/PyCQA/isort/commit/f7a6b0eea57e87155a367e2490b49b40f83c3944

(kontekst: https://pol.social/@mgorny/111010749186924187 )

#Gentoo #Python #pep517

#PythonPoetry strikes again. I don't even have the energy to comment on this anymore.

https://github.com/PyCQA/isort/commit/f7a6b0eea57e87155a367e2490b49b40f83c3944

(context: https://social.treehouse.systems/@mgorny/111010747338617783 )

#Gentoo #Python #pep517

Czy kogoś jeszcze dziwi, że idzie kolejny tutek z serii "jak złe jest #PythonPoetry" (poprzednio https://pol.social/@mgorny/111010749186924187)?

Tym razem: paczka nie deklaruje sekcji `build-system` w `pyproject.toml`, więc budowanie ze źródeł powoduje użycie `setuptools`, które nie buduje poprawnej paczki.

https://github.com/sayanarijit/expandvars/pull/65

#Python #pep517 #Gentoo

Is anyone surprised to learn that yet another toot continues my series on how bad #PythonPoetry is (previously https://social.treehouse.systems/@mgorny/111010747338617783)?

This time: a package that doesn't declare `build-system` in `pyproject.toml`, so building from source triggers implicit `setuptools` fallback that doesn't build a valid package.

https://github.com/sayanarijit/expandvars/pull/65

#Python #pep517 #Gentoo

Ok, it seems that github3.py is the first victim that I know of, of the war PyPI maintainers are waging against PyPA standards. Big sigh.

https://github.com/sigmavirus24/github3.py/pull/1144#discussion_r1174626625

#Python #pep517 #PyPI #PyPA #pep625 #hatchling