Giters

fpgmaas / deptry

Find unused, missing and transitive dependencies in a Python project.

Home Page:https://deptry.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Incorrect error when project contains dependencies that are also in the standard library

fpgmaas opened this issue · comments

commented

Describe the bug

Some projects contain dependencies that are also available in the standard library. For example, I recently came across a project that had asyncio listed as a dependency, whereas the documentation states:

This version is only relevant for Python 3.3, which does not include asyncio in its stdlib.

Usually this is simply a mistake; the user does not know that the package is part of the standard library, and they added it by mistake. Currently, deptry does not deal with that very well. For example, if asyncio is added as a dependency and it is used in the codebase, the user sees:

Scanning 1 file...

pyproject.toml: DEP002 'asyncio' defined as a dependency but not used in the codebase
Found 1 dependency issue.

For more information, see the documentation: https://deptry.com/

To Reproduce

Clone this example-project and follow the steps in the README.

Expected behavior

I think we should add a DEP005, which displays something like:

DEP005 'asyncio' defined as a dependency but it's part of the standard library
commented

Since we don't handle conditional markers for dependencies, couldn't this cause false positives if there are 3rd party libraries that end up being added to the standard library, for projects supporting multiple Python versions?

Although to be fair, this doesn't happen that much, and latest example that comes to mind is tomllib, based on tomli, which got a rename to avoid import conflicts.

commented

@mkniewallner good point, I also raised this as a limitation in the description of the PR. In my opinion this risk is limited due to the limited amount of packages (if any?) that were on PyPI and then got added to the standard library with the same name, and thus the risk is acceptable. Should it become an issue in the future we could consider parsing the conditional python markers.

commented

@mkniewallner good point, I also raised this as a limitation in the description of the PR. In my opinion this risk is limited due to the limited amount of packages (if any?) that were on PyPI and then got added to the standard library with the same name, and thus the risk is acceptable. Should it become an issue in the future we could consider parsing the conditional python markers.

Oh sorry, I did not see that there was an attached PR. Risks are indeed rather limited. And if we were to handle Python markers, the scope is actually larger than this new check.

Thinking back about it, I feel like relying on Python itself to get standard library modules at runtime in #275 is actually not that good of an idea, since this would prevent handling conditions for Python versions on projects that support multiple versions. I'll have to put more thoughts on it though.

Going back to the issue, I'm OK with adding this new check, will review the PR.