#setuptools — Public Fediverse posts

Es ist unfassbar, wie viele compatibility layers man installieren muss, um #Keras in #R zum laufen zu bringen.

Ich weiß schon, dass manche #Quants #Python nicht mögen, aber c'mon, ich habe gerade ein #JavaSDK installiert, um die #setuptools für den r-Keras-Wrapper aufsetzen zu können. Reeeeeaaaaaly?! 🧐

#Python is just doing great. We're not having impossible constraints, as some projects need old #setuptools for pkg_resources, and other projects are starting to require newer setuptools for some fancy new features. And ofc after promising to release pkg_resources standalone over a month ago, setuptools upstream didn't deliver.

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

#Gentoo

#Python is just doing great. We're not having impossible constraints, as some projects need old #setuptools for pkg_resources, and other projects are starting to require newer setuptools for some fancy new features. And ofc after promising to release pkg_resources standalone over a month ago, setuptools upstream didn't deliver.

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

#Gentoo

Aaand we're seeing the first '#setuptools < 82' runtime dependencies in random packages because they are trying hard to workaround breakage due to pkg_resources removal.

#Python

Aaand we're seeing the first '#setuptools < 82' runtime dependencies in random packages because they are trying hard to workaround breakage due to pkg_resources removal.

#Python

El mismo síntoma, pero meses después. Ahora es una actualización de setuptools la que genera el error del módulo pkg_resource no encontrado. Si presentas este problema, debes fijar la versión de setuptools en 81 o anterior.

https://www.cosmoscalibur.com/es/blog/2025/modulo-pkg-resources-no-encontrado-en-ambientes-uv/

#python #setuptools #pkg_resource

El mismo síntoma, pero meses después. Ahora es una actualización de setuptools la que genera el error del módulo pkg_resource no encontrado. Si presentas este problema, debes fijar la versión de setuptools en 81 o anterior.

https://www.cosmoscalibur.com/es/blog/2025/modulo-pkg-resources-no-encontrado-en-ambientes-uv/

#python #setuptools #pkg_resource

Lessons from this week's removal of the #pkg_resources module:

- If you don't use the `--no-build-isolation` argument of `pip install`, then `--require-hashes` is only partly effective and your builds may break whenever incompatible changes are made to #setuptools or other build dependencies.

- If you use `--no-build-isolation`, you need multiple `pip install` calls: first for all the needed build dependencies (a.k.a. `setup_requires`), then for the packages you actually want.

#Python #pip

Lessons from this week's removal of the #pkg_resources module:

- If you don't use the `--no-build-isolation` argument of `pip install`, then `--require-hashes` is only partly effective and your builds may break whenever incompatible changes are made to #setuptools or other build dependencies.

- If you use `--no-build-isolation`, you need multiple `pip install` calls: first for all the needed build dependencies (a.k.a. `setup_requires`), then for the packages you actually want.

#Python #pip

Setuptools deprecated pkg_resources in docs for ~two years, then with a DeprecationWarning for ~two years, then a UserWarning for ~one year.

2021-04: Deprecate in docs (v56.0.0)
https://github.com/pypa/setuptools/commit/8fe85c22cee7fde5e6af571b30f864bad156a010

2023-03: Officially deprecate with DeprecationWarning (v67.5.0)
https://github.com/pypa/setuptools/pull/3843

2025-05: Promote to UserWarning with earliest removal deadline of 2025-11-30 (v80.9.0)
https://github.com/pypa/setuptools/pull/5014

2026-02: Remove (v82.0.0)
https://github.com/pypa/setuptools/pull/5007

#Python #setuptools #pkg_resources

Setuptools deprecated pkg_resources in docs for ~two years, then with a DeprecationWarning for ~two years, then a UserWarning for ~one year.

2021-04: Deprecate in docs (v56.0.0)
https://github.com/pypa/setuptools/commit/8fe85c22cee7fde5e6af571b30f864bad156a010

2023-03: Officially deprecate with DeprecationWarning (v67.5.0)
https://github.com/pypa/setuptools/pull/3843

2025-05: Promote to UserWarning with earliest removal deadline of 2025-11-30 (v80.9.0)
https://github.com/pypa/setuptools/pull/5014

2026-02: Remove (v82.0.0)
https://github.com/pypa/setuptools/pull/5007

#Python #setuptools #pkg_resources

Accessing github from work is annoying.

I hope someone else in the world files a bug soon on flake8 not being compatible with a fresh python 3.12+ virtualenv, now that setuptools 82 is out and flake8 is still using the deprecated (now removed) pkg_resources.

#flake8 #python #setuptools

Accessing github from work is annoying.

I hope someone else in the world files a bug soon on flake8 not being compatible with a fresh python 3.12+ virtualenv, now that setuptools 82 is out and flake8 is still using the deprecated (now removed) pkg_resources.

#flake8 #python #setuptools

happy `ModuleNotFoundError: No module named 'pkg_resources’` day to all who celebrate #setuptools

happy `ModuleNotFoundError: No module named 'pkg_resources’` day to all who celebrate #setuptools

I hear that #Python folk are going to enjoy their Monday.

https://setuptools.pypa.io/en/stable/history.html#v82-0-0

Yep, #setuptools removed pkg_resources.

Thanks to Eli Schwartz for the advance warning. We're going to mask it in #Gentoo.

EDIT: I've started a DPO thread for this: https://discuss.python.org/t/pkg-resources-removal-how-to-go-from-there/106079

I hear that #Python folk are going to enjoy their Monday.

https://setuptools.pypa.io/en/stable/history.html#v82-0-0

Yep, #setuptools removed pkg_resources.

Thanks to Eli Schwartz for the advance warning. We're going to mask it in #Gentoo.

EDIT: I've started a DPO thread for this: https://discuss.python.org/t/pkg-resources-removal-how-to-go-from-there/106079

I need some help packaging a python module that I built. It references a few different python files, and .csv within the folder structure, and searching leads me to examples/tutorials that are either too simple, or way too complex. I can't find anything bridging the gap.

Any blogs, courses, tutorial, or even as a last resort youtube videos, that may help me out? #python #packaging #flit #setuptools #hatchling

The project that I'm trying to package is here - https://git.jmkengineering.com/JMK_Engineering_Inc/JEPL/src/branch/main/jepl

I need some help packaging a python module that I built. It references a few different python files, and .csv within the folder structure, and searching leads me to examples/tutorials that are either too simple, or way too complex. I can't find anything bridging the gap.

Any blogs, courses, tutorial, or even as a last resort youtube videos, that may help me out? #python #packaging #flit #setuptools #hatchling

The project that I'm trying to package is here - https://git.jmkengineering.com/JMK_Engineering_Inc/JEPL/src/branch/main/jepl

Last week I was a little annoyed about missing Microsoft C++ Build Tools #MSVC on a system without admin rights. I needed a compiler for building the #python C++ extension I developed a while ago. Annoyed not because I could not ask someone to install it for me, but annoyed because of the lack of compiler choices in this particular case. I have to use the MSVC instead of let's say #g++ which I could easily install via the #MinGW-w64 #conda package myself.

I found out that I can tell #setuptools (the backend build system) via #pip config settings to use a different compiler during build:

@stfn @cofiem @bkim If versioning via `pyproject.toml`is a concern then you might want to take a look at `setuptools_scm` which takes care of that via Git tags.

Workflow then becomes quite simple...

1. tag a commit
2. tag triggers CI to build and publish package (conditional on format of tag matching a pattern e.g. `v*`)

https://setuptools-scm.readthedocs.io/en/latest/

GitHub example (should be adaptable to Woodpecker)

https://github.com/AFM-SPM/TopoStats/blob/main/.github/workflows/pypi.yaml

(check `pyproject.toml` in that repo too).

#python #setuptools

@stfn @cofiem @bkim If versioning via `pyproject.toml`is a concern then you might want to take a look at `setuptools_scm` which takes care of that via Git tags.

Workflow then becomes quite simple...

1. tag a commit
2. tag triggers CI to build and publish package (conditional on format of tag matching a pattern e.g. `v*`)

https://setuptools-scm.readthedocs.io/en/latest/

GitHub example (should be adaptable to Woodpecker)

https://github.com/AFM-SPM/TopoStats/blob/main/.github/workflows/pypi.yaml

(check `pyproject.toml` in that repo too).

#python #setuptools

Some users reported that the #Dirsearch installer in bashcore-injector failed on #Debian 13.1.

The issue was a mix of packages: #pip from #APT vs #setuptools installed via pip, causing uninstall-no-record-file errors when pip tried to upgrade.

Fixed the script to handle this properly.

Updated bashcore-injector.tar.gz is now available at https://bashcore.org

#Linux #BashCore

Some users reported that the #Dirsearch installer in bashcore-injector failed on #Debian 13.1.

The issue was a mix of packages: #pip from #APT vs #setuptools installed via pip, causing uninstall-no-record-file errors when pip tried to upgrade.

Fixed the script to handle this properly.

Updated bashcore-injector.tar.gz is now available at https://bashcore.org

#Linux #BashCore

Our August 2025 Debian Contributions report is out! We have updates on preparing for the setup.py install deprecation in setuptools, Salsa CI, the Debian 13 “trixie” release and more.

Full report here: https://www.freexian.com/blog/debian-contributions-08-2025/

We thank the organizations subscribing to our Long Term Support contracts (https://www.freexian.com/lts/) and consulting services (https://www.freexian.com/services/) for making this possible.

#freexian #debian #trixie #setuptools #salsaci

Our August 2025 Debian Contributions report is out! We have updates on preparing for the setup.py install deprecation in setuptools, Salsa CI, the Debian 13 “trixie” release and more.

Full report here: https://www.freexian.com/blog/debian-contributions-08-2025/

We thank the organizations subscribing to our Long Term Support contracts (https://www.freexian.com/lts/) and consulting services (https://www.freexian.com/services/) for making this possible.

#freexian #debian #trixie #setuptools #salsaci

[Перевод] Что с Python? Меньше производительности, никакого сахара и больше багов

Python продолжает меняться, но не всегда так, как ждёт сообщество. Новый синтаксический сахар отклоняют, прирост производительности оказывается скромнее обещанного, а очередные депрекации в setuptools ломают проекты. При этом экосистема получает долгожданный стандартный lock-файл и поддержку uv в Dependabot. В статье разбираем, что это значит на практике и почему начинающим Python-разработчикам важно следить за этими изменениями.

https://habr.com/ru/companies/otus/articles/944160/

#python #Python_314 #производительность_Python #pep #синтаксический_сахар #зависимости #setuptools #Dependabot

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

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

A #nixos #flake that builds a #derivation that #package & install #nomadnet 0.1.0 & #meshchat 1.1.0 from #github python source code. For #reticulum #network. This is a beta work in progress, done using chatGPT iteratively, and is my first attempt at packaging something for nixos. Time will tell if this holds up. Uses python #setuptools & #buildPythonPackage
#lxmf ver 0.8.0
#rns ver 1.0.0 https://codeberg.org/adingbatponder/reticulum_nixos_flake

#nixospackages This is experimental and beta - see readme file for issues

A #nixos #flake that builds a #derivation that #package & install #nomadnet 0.1.0 & #meshchat 1.1.0 from #github python source code. For #reticulum #network. This is a beta work in progress, done using chatGPT iteratively, and is my first attempt at packaging something for nixos. Time will tell if this holds up. Uses python #setuptools & #buildPythonPackage
#lxmf ver 0.8.0
#rns ver 1.0.0 https://codeberg.org/adingbatponder/reticulum_nixos_flake

#nixospackages This is experimental and beta - see readme file for issues

Nowości w świecie Pythona: #setuptools teraz zawiera zagnieżdżone zależności z licencją LGPL. Nie żeby mi to robiło różnicę (aczkolwiek są ludzie i firmy, dla których to stanowi problem) — ale te zależności nie są nawet używane! Na przykład `autocommand` to zależność kilku skryptów w `jaraco.text`, które nie są używane przez setuptools.

A czekaj, jednak mi to robi różnicę, bo muszę poprawić LICENSE w dev-python/ensurepip-setuptools.

https://github.com/pypa/setuptools/issues/5045
https://github.com/pypa/setuptools/issues/5049

#Python

New in #Python world: #setuptools now vendors deep dependencies with LGPL license. Not that I do mind (but some people and companies do!) — but these dependencies aren't even used! I mean, `autocommand` is just a dependency of some scripts in `jaraco.text` that aren't used by setuptools.

Oh, wait, I actually do care, because I need to fix LICENSE in dev-python/ensurepip-setuptools.

https://github.com/pypa/setuptools/issues/5045
https://github.com/pypa/setuptools/issues/5049

New in #Python world: #setuptools now vendors deep dependencies with LGPL license. Not that I do mind (but some people and companies do!) — but these dependencies aren't even used! I mean, `autocommand` is just a dependency of some scripts in `jaraco.text` that aren't used by setuptools.

Oh, wait, I actually do care, because I need to fix LICENSE in dev-python/ensurepip-setuptools.

https://github.com/pypa/setuptools/issues/5045
https://github.com/pypa/setuptools/issues/5049

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

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

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.

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

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

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

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

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

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

(Note: credit where credit is absolutely do: setuptools team stepped up and embraced the issue, putting together a very quick rollback to unbreak everybody and move the deprecation deadline further out. That was extremely responsible.)

#python #setuptools