Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address deprecation of setup.py direct invocation #109

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mara004
Copy link
Contributor

@mara004 mara004 commented Nov 19, 2023

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.

Fixes: "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."
@mara004
Copy link
Contributor Author

mara004 commented Nov 19, 2023

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.

@mara004 mara004 marked this pull request as ready for review November 19, 2023 20:30
@rom1504
Copy link
Collaborator

rom1504 commented Nov 19, 2023

this PR is not removing setup.py

@mara004
Copy link
Contributor Author

mara004 commented Nov 20, 2023

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
Copy link
Contributor Author

mara004 commented Nov 21, 2023

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

@extremeheat
Copy link
Owner

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
Copy link
Contributor Author

mara004 commented Nov 25, 2023

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants