After literal decades of work, #setuptools maintainers are finally retiring #pkg_resources in v82.0.0. I've been diligent to migrate every package I came across that used it for years, but it's very likely still being used in the wild, so here's a bit of context if you see failing builds in the coming days and don't understand what's happening;
#pkg_resources was shipped alongside #setuptools, which has been the de-facto standard (and only option up until ~2018 (#PEP517)) build backend for #Python packages. #setuptools was *never* part of the standard library, however it used to be (and still is, in many cases) distributed with it for convenience, so many projects have depended on it for ages, some of which have never explicitly declared it as a dependency (neither build-time or runtime). #pkg_resources had the same exact problems, but worse, because you couldn't even find it on #PyPI under its own name. I suspect many Python dev will only learn about this now that the package is suddenly missing.
In many cases, solutions include:
- migrating to importlib.metadata (python>=3.8), or its third party counterpart #importlib_metadata if somehow you still need to support Python 3.7 or older
- migrating to importlib.resources (Python>=3.11), or #importlib_resources for older Pythons
- dropping #setuptools / #pkg_resources completely: if all you need is a dead-simple, well maintained build backend for pure-Python projects, I highly recommend #flit_core. It's trivial to use, only supports static metadata and has never blown my face away after years using it every chance I get.

If you read this far, please boost for reach. Thanks !

#packaging #dependency #dependency_hell #softwaredevelopment

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.

#Python