@pganssle thanks, yes I've seen this python version issue being described there, I was wondering if there is anything else. I am going to dust off this project, start producing wheels etc. and I need to make sure the metadata are correct even if the tooling is out of date.

I read the "setup.py test" issue before and I must say I understand why the situation is so heated now.

@pganssle I guess you must be tired of this, but let me share my personal frustration with you:

ca. 2020 I inherited (another) project and wanted to convert it to something resembling current state of affairs, modern setuptools, tox, etc. We used pyscaffold 3.x to help us with that and we ended up with a sane minimal-setup.py, almost-everything-in-setup.cfg setup with setuptools_scm. This all worked fine until had to introduce cryptography and this all was in vain since RHEL 8 pip is old /cont

@pganssle so we got caught in the cryptography rust surprise like probably many other people. So now I carved out something that makes sure modern setuptools, wheel, pip, C compilers, swig, rust and other stuff gets installed on top of the obsolete RHEL things, but now i read.... I should not install setuptools globally.

Pyscaffold 4 requires some very recent version of tox (because of one little thing) so we will need to overwrite RHEL-installed global tox too. Distro lag is a major issue...

@saper I think this is a general problem, and not one that’s easy to fix. Software is an ecosystem, and even stable ecosystems are in some form of dynamic equilibrium, with a constant ebb and flow that tends to wear away static elements.

How you want to orchestrate your builds really depends on you. All the distro packagers do install setuptools globally, but that’s because they are trying to maintain a separate packaging stack.

@saper If you are using the normal Python stack, you basically just have to bootstrap to the point where you can get some sort of isolated environment that you can run pip or some equivalent in.

Most of the reason distro folks don’t usually like doing that sort of thing is because of some notion of mitigating supply chain risks by always installing from “source”.

I think this is mostly security theater (though there’s some core of value to it), but python -m build came about mainly because the Arch folks wanted a simple standards-compliant way to bootstrap the build ecosystem.

@saper So you may want to try from that entry point — bootstrap build and use that to build wheels for your whole dependency tree yourself. You can do it in a chroot or a docker container or whatever isolated environment mechanism your build system uses to separate context-specific dependencies.

@pganssle also - big thanks for this post. It is very informative and #Python needs more stuff like this!