Address deprecation of setup.py direct invocation

[mara004]

Fixes

SetuptoolsDeprecationWarning: setup.py install is deprecated.
Please avoid running setup.py directly.
Instead, use pypa/build, pypa/installer or other standards-based tools.
See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details.

One problem with direct invocation is that there isn't really a reasonable way to install setup-time dependencies like setuptools itself. Therefore it was decided a separate tool should be called instead that can handle setup dependencies cleanly, usually via a pyproject.toml [build-system] table.

[mara004]

In the future, it would also be good to move away from setup.py completely and use pyproject.toml/setup.cfg instead.

AFAIK, PyPA would like callers to migrate to purely declarative configuration where possible, to avoid arbitrary project code execution on sdist install, and limit the scope to a set of trusted backends that merely apply a declarative config.

I don't think this can ever be enforced, as there are projects with foreign language extensions (or other special needs) that will continue to depend on dynamic setup, but PyPA could e.g. require explicit user confirmation in the future before pip install running setup.py internally.

[rom1504]

this PR is not removing setup.py

[mara004]

this PR is not removing setup.py

Correct. setup.py itself also isn't deprecated, just calling it directly.
Though nowadays it's considered bad practice to use setup.py if it can be avoided.
That's what the comments above were supposed to explain.

This PR just addresses the imminent deprecation, because that's a very simple fix.
I imagined the metadata migration could be done later in a separate PR.

[mara004]

I think I should yet add a pyproject.toml buildsystem stub in order to use PEP 517, though.

[extremeheat]

Yeah, moving to the toml file would be great. There isn't anything fancy to do in the current setup.py so making the move should be pretty easy. And the release/command workflows should already support it.

[mara004]

There isn't anything fancy to do in the current setup.py so making the move should be pretty easy.

+1

And the release/command workflows should already support it.

Sorry, I'm not sure what you mean with this? They currently call setup.py directly; that's what this PR changes...
Anyway, it's a very simple change too.

[extremeheat]

I meant that the correct fix should be moving to the .toml file