How to handle tools (not imported) that end up being reported as "unused" dependencies

[jherland]

From #112 (comment):

Rather I think this is a (separate) issue with FD: When calculating/presenting "unused" dependencies, we should consider ignoring/skipping common tools that are typically declared as dependencies but seldom imported. Examples, just from our own project config:

• black
• isort
• codespell
• mypy
• nox
• pylint
• pytest
• fawltydeps 🎉

Maybe we could try to be smarter about it, like looking for tool configurations in pyproject.toml as proof that a tool is actually being used? But I suspect a simple allow-list might be good enough.

More thought is probably needed about how best to solve this, but we will probably want to do something about this fairly soon, as there are enough of these tools that will keep showing up as "unused dependencies"...

[Nour-Mws]

Adding to the list above:

• wheel
• types-setuptools

A quick fix could be to report those in a different category in the human-readable output:

These dependencies were not imported in your code but are common development dependencies:

• pylint
• mypy
• ...

[jherland]

Maybe. I'm a little afraid of making the output too complex. I guess the average user wants a green "all OK" or a red "these must be fixed" result, and these are somewhere in-between, depending on context.

I'd rather provide them with an option for controlling whether or not we consider common dev tools as unused, and simply use that to include/exclude them in the "unused" result. Maybe something like:

These dependencies appear to be unused (i.e. not imported).
If they are used in other ways, consider adding them to extra_declared_deps
in the [tool.fawltydeps] section of pyproject.toml:

[zz1874]

Based on our discussion today, we agreed on using a default list for the ignore_unused dependencies (with known dev deps) that will be overridden when the user provides their own list.
This should not normally interfere with reported undeclared deps (if you import isort, and it is in both declared and ignore_unused, it shouldn't be reported as undeclared).

I'll list the dev dependencies (not complete version) here:
Development tools not meant to be imported:

• black
• codespell
• colorama
• coverage
• fawltydeps
• flake8
• hypothesis
• isort
• mypy
• nox
• pylint
• pyright
• pytest
• tox
• wheel

[Nour-Mws]

Thanks Zhihan! I am not sure about colorama. Why would we need to explicitly include it in the ignore_unused? If it's only a dependency of a dependency and not a direct dependency, it shouldn't appear in the dependency configuration file to begin with. Or am I missing something?

[zz1874]

Oh thanks for spotting this! Actually colorama is a direct dependency in the dev group of our pyproject.toml, I've updated the list to avoid ambiguity.

[jherland]

If we're hardcoding a list of tools that FawltyDeps should ignore_unused by default, I think it's very important that it covers as many commonly used tools as possible. This is something that our PyPI experiment should help uncover.

The above is a good starting point, but we should not believe that we're anywhere near finished curating this list... 😅

[Nour-Mws]

Attempting to complete the list:

[
    "autopep8",  # Automatic PEP 8 formatting
    "mccabe", # complexity plugin for flake8
    "pre-commit",  # Pre-commit hooks
    "pyformat", # Formatting
    "pytest-cov",  # Coverage plugin for pytest
    "pytest-mock",  # Mocking plugin for pytest
    "pytest-xdist",  # Parallel test execution
    "bandit",  # Security static analysis
    "sphinx",  # Documentation generation
    "recommonmark",  # Markdown support for Sphinx
    "sphinx-rtd-theme",  # Theme for Sphinx
    "pydocstyle",  # Docstring style checking
    "pyflakes", # Formatting
    "rope",  # Refactoring
    "ruff", # Linting in Rust
    "twine",  # Package publishing
    "unify", # unifying quote styles
    "yapf",  # Yet another code formatting option 
]

I think it makes to also split those (with a separator comment inside the list) into their respective groups (formatting, linting, security, documentation, etc.. )

[jherland]

Thanks for digging into this @Nour-Mws. Note that I'm happy to ship an incomplete list in the initial version of this, as long as we are prepared to add more tools that people suggest.

I'm not familiar with most of the tools in the above list. Most of them seem like tools you'd run from the command-line, but I'm not sure about the pytest-* packages?

Should we have a different mechanism for pytest-* packages, maybe something more similar to how we handle type stubs?

[Nour-Mws]

I'm not sure about the pytest-* packages?
Should we have a different mechanism for pytest-* packages, maybe something more similar to how we handle type stubs?

I agree. It makes more sense not to include them here.

[zz1874]

Thanks @Nour-Mws 👍 ! I've updated the list with your inputs in bbd8308 (and also excluded pytest-* packages).

[jherland]

Copying my comment from the PR, as it probably rather belongs in this dicussion:

In general, do we want to consider a more general solution to these categories of plugin packages? Maybe allowing simple globs like pytest-* and sphinx-* in this set? (although this will add complexity to our matching algorithm in fawltydeps/check.py).

But I'm also very happy to leave this as-is for now. We can always reconsider later if/when we see that more of these packages need to be added.