Slightly broaden Ruff, and update and clarify tool configuration by EliahKagan · Pull Request #1871 · gitpython-developers/GitPython (original) (raw)

Although it seems likely that the requirements-dev.txt file will be removed when the project definition is made declarative (discussed in gitpython-developers#1716 comments), if not before, for now it exists and might be in use, so this updates it with tools that are currently used but not listed in any extras or other requirements files:

• ruff: This has replaced flake8 and its plugins (gitpython-developers#1862) as well as black (gitpython-developers#1865). Currently there is no separate extra for tooling that is not part of unit testing, with some such tools listed in test-requirements.txt. The ruff package belongs here rather than there for now because it should not be installed just to run unit tests, since Ruff has to be built from source on some rarer platforms like Cygwin, which would take a long time and/or fail.

• shellcheck: The PyPI package for this is a convenience for installing it in projects that are already using pip (shellcheck is neither written in Python nor a tool to scan Python code). It installs pre-built binaries, which are not available for all platforms.

These packages remain listed:

• pytest-icdiff: This seems not to have been promoted to be in the test-requirements.txt file and the test extra because it does not work as well for diffs from tests that the pytest runner runs but that are written for the unittest framework.

• pytest-profiling [commented out]: I am not sure what the status of this is, perhaps it has just not been experimented with enough to know if it would be useful for profiling in GitPython.

This requirements-dev.txt file has a few limitations that suggest it should be removed altogether sometime soon:

• It is not updated regularly.

• It is not always clear why something is there. Originally I believe it was for tools where the desire to use the tool was established but the tool did not yet work or worked but performed checks for which code had to be fixed. That purpose has drifted.

• It uses a different naming convention from the test-requirements.txt file in active use.

• It cannot be readily used to create an extra in the current project definition in setup.py because the simple parsing done there will not recognize the -r lines and will not skip the comments, and neither enhancement should be done in setup.py since that would move things farther away from a declarative project definition.

• It will naturally go away when the project definition is made declarative, since it will then be feasible to define as many extras as desired without proliferating separate requirements files (while still allowing their contents to be statically available to tools).

Since it may go away soon and is not regularly updated, I have kept the explanations for why particular packages are there out of it. But as long as it exists it may as well list the tools that really are being used yet are not explicitly listed as dependencies.