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

Non-imported development dependencies are already listed and make up most of the false positives #3

Open
matthewdeanmartin opened this issue May 26, 2024 · 3 comments

Comments

@matthewdeanmartin
Copy link

matthewdeanmartin commented May 26, 2024

Here is the config I used.

It says all my development deps are unused (the are command line tool and are not expected to be imported). But I took the time to ask the bot to write a script to convert poetry to PEP621 deps and the dev deps are listed under [project.optional-dependencies]

To be clear, how cli tools are executed doesn't matter. What matters is there is a perfectly fine list of them in the dev dependencies section and I'd rather tell the tool to use that list instead of rewriting it.

@ucodery
Copy link
Owner

ucodery commented May 28, 2024

I believe that bonded is correctly identifying your optional-dependencies from pyproject.toml, but not finding their use because currently Makefiles are not supported.

Currently bonded will flag a dependency as in use if it provides at least one executable script that is called by the project. You are calling those executables, but not in one of the supported files. In order to limit false-positives bonded only searches python, shell, and certain config files for the names of executables to determine "in use". It is entirely reasonable to expect Makefiles to be in that search list.

@ucodery ucodery changed the title How do I exclude development dependencies without manually listing them *again* Support executable discovery in Makefiles May 28, 2024
@matthewdeanmartin
Copy link
Author

matthewdeanmartin commented May 29, 2024

Oh my I titled this poorly. Let me fix it by removing the word Makefile as that was an awful distraction.

Here are some tools that are NEVER imported (the docs sometimes say, don't import or we will wreck your code next release:

tox
pytest (sometimes imported)
pip
ruff
pylint
isort
mypy

Now lets look at some patterns. Every single one of these normally appears in the development dependencies. There isn't a "development dependencies that are imported" (exceedingly rare) and "development dependencies that are never imported" section (exceedingly common).

Sometimes you can pipx globally install these and keep them out of the venv entirely, but tools like mypy that doesn't work unless installed in the same venv that it is inspecting.

I'm saying why should I repeat the dev dependencies list when it is right there waiting to be used?

This is your sideproject and you can do anything you'd like, I'm just reporting the DX.

@matthewdeanmartin matthewdeanmartin changed the title Support executable discovery in Makefiles Non-imported development dependencies are already listed and make up most of the false positives May 29, 2024
@ucodery
Copy link
Owner

ucodery commented May 29, 2024

I placed "Makefile" in the title, sorry if that confused.

I know that dev dependencies are almost never imported anywhere in the project. And that is why bonded has always also searched for the calling of executable scripts provided by dependencies and, if found, marks the dependency as used (though with a lower confidence score than an actual import).

This has worked in other project I've used bonded with because the dev task managers were searched (nox, tox...) but this project uses a job description/execution format not supported (Makefile) which I would like to support.
The current behaviour allows e.g. cryptography to depend on nox and pytest in project.optional-dependencies and not have to exclude them.

But I think you may be requesting that bonded simply skip optional-dependencies or at least one key in optional-dependencies, when asked by the user? Which is a reasonable request, one that is separate from making execution detection better.

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

No branches or pull requests

2 participants