Incorrect error when project contains dependencies that are also in the standard library
fpgmaas opened this issue · 3 comments
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
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.
@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.
@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.