This is kind of a followon to the “Best practice…” topic, from an application viewpoint.
We’ve actually had users find old documentation and try to “python setup.py install” and it fails for them, so we’re motivated to pretty actively discourage it, but hopefully without immediately breaking people for whom it still works. I know one approach is to just get rid of it, but as we’ve seen elsewhere, that’s likely to break Linux distro packagers and others whose stanzas still look like (taken from the current Fedora specfile for us):
That quote is from an outdated or unmaintained spec file. It does not follow recent Fedora Python packaging guidelines. A modern spec files should use the pyproject RPM macros such as %pyproject_wheel + %pyproject_install. Projects that don’t support wheel building may still use the old style %py3_build / %py3_install macros. Here is how the spec file for black looks like.
No. RHEL7 predates PEP 516 & PEP 517, and RHEL8 predates the deprecation of calling setup.py directly (and the tooling improvements that made the alternative usable). For those systems, stick with yesteryear’s best practice.
Packagers can provide different instructions for different systems in a separate Git branches, or with %if/%else in the spec file.
Note that the snippet from the original post is from such an %else block, so it isn’t actually for Fedora (where hardcoding Python 3.8 wouldn’t really work). The Fedora part can be updated.
… plus some additional fiddling that isn’t material here.
with my original snip in the else past.
However, the intent of my question wasn’t to poke at Fedora, but to ask in general, I don’t think everybody has done this kind of work yet. Can I safely put something in setup.py itself that gives information to someone manually running the setup.py without breaking a distro package which maybe also calls setup.py, or tools like build, which end up invoking setup.py as a command?