python: stop using setup.py as a CLI tool

[cwegener]

Issue

setup.py does not want to be a CLI tool

The setuptools team no longer wants to be in the business of providing a command line interface and is actively working to become just a library for building packages. What you should do instead depends on your use case, but if you want some basic rules of thumb, there is a table in the summary section.
This does not mean that setuptools itself is deprecated, or that using setup.py to configure your package builds is going to be removed. The only thing you must stop doing is directly executing the setup.py file — instead delegate that to purpose-built or standards-based tools, preferably those that work with any build backend.

https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

Action

Migrate the python packaging output code to use another CLI tool (e.g the build module from PyPA ... https://github.com/pypa/build)

[jordansissel]

I agree we should better align with upstream python’s recommendations. In such a case, we may need to figure out what versions/environments support which build steps. In the case of PyPA, it seems the first release was in 2020, and that’s pretty recent to require such a thing given some fpm users likely have Python versions much older than that year, so i would like it if we can do this without negative impacts on those users. Any thoughts?

[cwegener]

In the case of PyPA, it seems the first release was in 2020, and that’s pretty recent to require such a thing given some fpm users likely have Python versions much older than that year, so i would like it if we can do this without negative impacts on those users. Any thoughts?

pypa/build was a quick example that popped in my head because I used it a lot as the main CLI tool.

pypa/build is indeed a frontend for PEP-517/PEP-518 which are from 2015/2016 era.

As a minimum, for pypa/build to work as a build frontend, the python source dist must have the PEP-517 pyproject.toml implemented (which is the [build-system] table part of pyproject.toml). IIRC pypa/build might still be able build a python source dist if the rest of the information (i.e. the project metadata) are still stored and accessed via setup.py / setup.cfg

So, practically, the cut-off point would be that only PEP-517 compliant projects would be supported, which in my real-world experience would still be quite limiting at the moment. I still see a lot of old open-source projects around that have the build instructions.

Scratch that. There is also "legacy setup.py" support in pypa/build ... but some projects with REALLY highly customized setup.py scripts will fail to build. But the build failures from the new setuptools package (which pypa/build invokes) are really helpful for resolving this legacy issues.

So, I think the number of packages that will be impacted by such change will actually be quite small.

[cwegener]

So, I think the number of packages that will be impacted by such change will actually be quite small.

Specifically, the likely packages that will be impacted would fall into these categories:

1. Active projects (likely OSS projects) who have complex build scripts (either for valid reasons or unnecessarily complex) and those projects will have to deal with the move from setup.py as a CLI to a PEP-517 frontend anyway.
2. Dormant projects who have complex build scripts, and therefore when fpm users face this change, the fpm users won't have anybody to talk to about resolving potential failures of running these complex setup.py scripts via pypa/build legacy backend.

Category 1 are going to be projects mainly in OSS but also in Private orgs.

Category 2 are probably going to be more prevalent in Private orgs? Not sure.

EDIT

Keeping in mind, that amongst these projects, there then will be a certain success/fail ratio of whether the legacy setup.py script will run successfully through the pypa/build frontend's legacy support.