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

Deprecated setuptools features are used #1653

Closed
EliahKagan opened this issue Sep 10, 2023 · 0 comments · Fixed by #1654
Closed

Deprecated setuptools features are used #1653

EliahKagan opened this issue Sep 10, 2023 · 0 comments · Fixed by #1654

Comments

@EliahKagan
Copy link
Contributor

EliahKagan commented Sep 10, 2023

This project currently uses deprecated features of setuptools, some of which may be removed in the future.

  • Installing by running setup.py directly, as the instructions in README.md say to do and as is done in test_installation, is deprecated. Actual breakage due to this begins in Python 3.12, where although setuptools is still supported as a build backend and nontrivial logic can still be used in setup.py, global and virtual environments do not automatically have the setuptools package. (See the ensurepip item in the list of removals in 3.12.) This is the cause of Python 3.12: ModuleNotFoundError: No module named 'setuptools' #1640. But the deprecation is not new as of Python 3.12. The following message appears during installation (with any Python version provided the installed setuptools version is not very old, but I used Python 3.11.5):

    /home/ek/repos-wsl/GitPython/.venv/lib/python3.11/site-packages/setuptools/_distutils/cmd.py:66: 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.
            ********************************************************************************
    
    !!
    

    This could be worked around without a fix by adding setuptools as a development dependency, but an actual fix is straightforward, and there are some further benefits to using pip install . to install locally, including that -e can easily be passed to make the installation editable.

  • Building by running setup.py directly is, if I understand correctly, also deprecated. This is a less serious problem, but a true fix for this is also straightforward: the build module can be added as a development dependency and used for building the sdist and wheel in Makefile. The setuptools documentation recommends using build.

  • The tests_require keyword argument is deprecated and intended for removal in a future version of setuptools, as noted in the setuptools.setup keyword arguments documentation.

    This is already not achieving what appears intended or least hoped for (see Readme claims test dependencies are installed automatically #1652), and one reasonable way to fix this is to remove that argument altogether. But both the reliance on a deprecated feature and the absence of an automated way to install test dependencies as a group (without pip install -r commands) could be remedied by using a test extra rather than tests_require.

Although I worry a bit about broad scope, it seems to me that it is natural to fix #1640, #1651, #1652, and this issue (which itself overlaps with #1640 and #1652, though is not limited to them) in a single pull request. I say this because there is significant overlap in the changes, and because decisions made in review should probably take the considerations of all these issues into account. I've opened #1654 for this.

Note that while it is today discouraged to implement nontrivial logic in setup.py, and recommended to use pyproject.toml and/or setup.cfg for what has traditionally been done in setup.py, I do not believe it is deprecated to make nontrivial use of setup.py as this project does. Although it would be beneficial to define build and installation rules declaratively, I think that would be a much bigger change than needed to fix this issue. I have not attempted to do anything like that at this time.

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

Successfully merging a pull request may close this issue.

2 participants