Jeśli nie uważacie, że myląca i słabo udokumentowana składnia `include` (przez którą ciągle odkrywam spieprzone paczki, patrz: https://fosstodon.org/@mgorny/109804621637966670, https://fosstodon.org/@mgorny/109551021232804550) to dostatecznie dobry powód, by odradzać #PythonPoetry, oto kolejny absurdalny problem:

Jeżeli zadeklarujesz zależność jako opcjonalną (`optional = true`), ale nie umieścisz jej w żadnej grupie `extra`… to ta zależność nie będzie opcjonalna. Żadnego ostrzeżenia o błędnej składni, nic. Problem znany od 3,5 roku:

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

A najlepsze jak ktoś ożywi wpółmartwą paczkę na tydzień, wyda nową wersję używającą Poetry, a potem przez kolejny rok będzie ignorować poprawki dla niepoprawnego użycia tego systemu budowania.

#Python #pep517 #Gentoo

Wydałem dziś #gpep517 w wersji 15, z wsparciem dla budowania cross-prefix. Innymi słowy, można teraz odpalić budowanie paczek przy pomocy systemu budowania #PEP517 używając interpretera Pythona, który jest zainstalowany w innym prefiksie niż używany przez sysroot.

Używając terminów ebuildów #Gentoo, teraz będziemy wywoływać:

```
gpep517 build-wheel ... \
--sysroot "${SYSROOT}" \
--prefix "${EPREFIX}/usr"
```

Wcześniej nie można było podawać `--prefix`, więc `${EPREFIX}` musiał być taki sam jak `${BROOT}`, czyli prefiks używanego interpretera. gpep517 wówczas szukałby danych w katalogu `${SYSROOT}${BROOT}/usr` (lub innym prefiksie używanym przez uruchomionego Pythona) — a teraz poprawnie będzie szukał w `${SYSROOT}${EPREFIX}/usr`.

Podziękowania dla Chewiego za łatkę!

https://pypi.org/project/gpep517/15/

#Python

Inne wiadomości ze świata #Python: nowy backend #pep517 #scikit-build-core okazuje się psuć #setuptools na jeszcze jeden sposób. Tym razem błąd zauważono przy wykorzystaniu #pdm-backend.

A, fail2ban też psuje. Może to ten sam problem.

scikit-build-core: https://github.com/scikit-build/scikit-build-core/issues/426
fail2ban: https://bugs.gentoo.org/909535
poprzedni bug (psuł rozszerzenia #RustLang): https://github.com/scikit-build/scikit-build-core/issues/413

Oznaczyłem paczkę #pdm-#pep517 jako przestarzałą w #Gentoo. Część z pozostałych wstecznych zależności już została zaktualizowana do użycia innego backendu, jedna ma już otwarty pull request, a pozostałymi trzema zająłem się sam (proponując migrację do pdm-backend):

https://github.com/abersheeran/a2wsgi/pull/35
https://github.com/gazpachoking/jsonref/pull/55
https://github.com/mkdocstrings/autorefs/pull/26

#Python

I've marked #pdm-#pep517 package deprecated in #Gentoo. Some of the remaining revdeps have already been migrated away in their VCS repositories, one has pull request open, and I've filed pull requests to migrate the remaining three to pdm-backend:

https://github.com/abersheeran/a2wsgi/pull/35
https://github.com/gazpachoking/jsonref/pull/55
https://github.com/mkdocstrings/autorefs/pull/26

#Python

Udało mi się wrzucić nową wersję #TranslateToolkit do #Gentoo.

- instalacja metodą #PEP517 była zepsuta i do systemu nie trafiały pliki danych (aktualna wersja stabilna paczki też jest popsuta i nikt nawet nie zauważył)

- testy spodziewają się, że pliki danych z translate-toolkit i gaupol znajdą się w tym samym katalogu, ${XDG_DATA_HOME}

- jeden z testów zmienia katalog roboczy przez os.chdir() i nigdy nie wraca, psując tym samym testy po nim następujące

- wszystkie testy zbudowane w oparciu o snapshottest się sypią i nie mam pojęcia dlaczego (a do tego wtyczka ta generuje paskudnie nieczytelne komunikaty błędów i w ogóle dlaczego ktokolwiek używa czegoś tak paskudnego?!)

Czuję się, jakbym właśnie zmarnował godzinę swojego życia.

#Python

I've managed to bump #TranslateToolkit in #Gentoo.

- #PEP517 install was broken and didn't install data files (it's also broken in current stable and nobody even noticed)

- tests expect data files from itself and gaupol in a single ${XDG_DATA_HOME}

- one test module does os.chdir() and never returns, breaking other tests

- all tests based on snaphottest fail and I have no clue why (also, the output is awful and why do people use such a horrible plugin?!)

Feels like an wasted hour.

#Python

Czy można sensowniej spędzać czas niż dodając wsparcie dla bezsensownej zmiany nazwy #NIH-owego backendu #PEP517, który był używany przez mniej niż dziesięć paczek? Pierwsza z nich (autorstwa autora owego backendu, oczywiście) właśnie wydała nową wersję jedynie w celu zmiany backendu, podczas gdy cała reszta będzie jeszcze długo wymagała starej paczki.

https://github.com/gentoo/gentoo/pull/31272
https://gitlab.com/warsaw/public/-/compare/3.1.1...3.1.2

#Gentoo #Python

Is there a better work to spend your time on than adding support for a pointless rename of a #NIH #PEP517 backend that was used by less than a dozen packages? The first one (by the backend's author, of course) just made a release purely for the purpose of switching to the rename, while the rest still block on the old package.

https://github.com/gentoo/gentoo/pull/31272
https://gitlab.com/warsaw/public/-/compare/3.1.1...3.1.2

#Gentoo #Python

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

Today's sigh: meson-python suddenly decided that they won't call `#meson compile` anymore and they'be calling #ninja directly instead. As a result, `compile-args` in the `config_settings` dict suddenly changed from passing meson options to passing ninja options.

Yes, you guessed right. This sudden API change broke our workflow.

https://bugs.gentoo.org/904677
https://github.com/mesonbuild/meson-python/issues/409

#Gentoo #Python #pep517

> PDM was created as a “Python package manager with PEP 582 support” (which is notable, given that PDM does not implement PEP 582).

(from https://pradyunsg.me/blog/2023/01/21/thoughts-on-python-packaging/, it references https://pradyunsg.me/blog/2023/01/21/pdm-does-not-implement-pep-582/)

#Python #pep517 #pdm

Did you know that #hatchling verifies the trove classifiers you're using? So even if you don't use any new feature, you need to put a lower bound on supported hatchling version, or some users may see build failures due to unrecognized trove classifiers.

https://github.com/tiangolo/fastapi/pull/9240

#Python #pep517

So it seems that #Gentoo is not the only distro stuck with old version of pydata-sphinx-theme because of how horrible sphinx-theme-builder is. That said, Fedora seems to have managed it… and it's so scary I don't think it's worth it. Why do software developers have to be so short sighted?

https://src.fedoraproject.org/rpms/python-pydata-sphinx-theme/blob/rawhide/f/python-pydata-sphinx-theme.spec#_80

#Python #pep517

I've just noticed that my bug about PEP 625 support in flit_core has the number… 626. One bug too late!

That said, I've finally gotten around to making a PR, and it turned out to be trivial! It's so nice that source distributions and wheels use the same rules, so you can just reuse the existing function.

https://github.com/pypa/flit/issues/626
https://github.com/pypa/flit/pull/628

#Python #pep517

pdm-backend just aligned its sdist and wheel naming to the current standards! This leaves setuptools as the only #pep517 backend I'm aware of using legacy naming.

https://github.com/pdm-project/pdm-backend/commit/df720d239c1f600dd1e655339e95968e71dd2191

#Python

Oh, on top of all the mess around different #pep517 build systems following different distribution filename normalization rules, it turns out that #PyPI doesn't accept wheels following the newer rules… because "the situation about what file names are acceptable is extremely messy right now" (as of July 2022).

Please tell me with a straight face that #Python packaging works.

https://github.com/pypi/warehouse/issues/10030

Some more #pep517 #Python fun.

Only hatchling, meson-python and poetry-core implement PEP 625 sdist naming.

All tested backends except for pdm-pep517 and setuptools implement the current wheel naming spec. These two use the older PEP 427 naming.

https://blogs.gentoo.org/mgorny/2023/02/09/naming-standards-compliance-of-pep517-backends/

It gets even better. It turns out that Poetry has an undocumented `build` key that doesn't work via poetry-core (sigh). It runs a script at build time that Box uses to build a C extension using distutils (sigh).

This is just the true pure horror that #pep517 introduced. Switching from setuptools to poetry just to add a hack that uses setuptools to plug what poetry can't do.

https://github.com/cdgriffith/Box/blob/0bfcb2d37ddc4c60f5aa48a8c258f8a324e24d18/build.py

Given that I've just discovered two more #Python packages installing random documentation files straight into top-level site-packages directory, I have only one thing to say:

Please do not use Poetry. It is the single worst #pep517 build system in history.

https://github.com/python-babel/flask-babel/pull/215
https://github.com/cdgriffith/Box/pull/245