Report locations of violations
mkniewallner opened this issue · 4 comments
Is your feature request related to a problem? Please describe.
deptry
currently does not report the locations of imports when reporting issues:
[...]
There were 2 dependency issues found.
-----------------------------------------------------
There are dependencies missing from the project's list of dependencies:
an_import
another_import
Consider adding them to your project's dependencies.
-----------------------------------------------------
There are transitive dependencies that should be explicitly defined as dependencies:
cfgv
They are currently imported but not specified directly as your project's dependencies.
[...]
This forces developers to search for dependencies by themselves.
Describe the solution you would like
In order for the error report to be more helpful, deptry
could report the exact locations of imports for each reported issue, similarly to what other linters like flake8
, ruff
or mypy
do.
The locations would be reported both in the console output, and the JSON one.
Additional context
While it could be rather straightforward to add the information in the JSON output, for the terminal output, it will probably require to rethink a bit how we currently report errors.
We could either go with a format similar to what Ruff
/flake8
use:
deptry/dependency_getter/base.py:1:1: I001 Import block is un-sorted or un-formatted
deptry/dependency_getter/base.py:8:17: F401 `abc.ABCMeta` imported but unused
Found 2 errors.
Which would translate, for deptry, to something like:
deptry/dependency_getter/base.py:11:11: DEP002 `an_import` imported but missing from the dependencies
deptry/dependency_getter/base.py:12:11: DEP002 `another_import` imported but missing from the dependencies
deptry/dependency_getter/base.py:13:11: DEP003 `cfgv` imported but it is a transitive dependency
deptry/dependency_getter/pdm.py:16:11: DEP002 `an_import` imported but missing from the dependencies
Found 4 dependency issues.
For more information, see the documentation: https://fpgmaas.github.io/deptry/
Or we could use another custom format that group issues together, like:
Found 4 dependency issues.
Missing dependencies:
* an_import -- imported over:
deptry/dependency_getter/base.py:11:11
deptry/dependency_getter/pdm.py:16:11
* another_import -- imported over:
deptry/dependency_getter/base.py:12:11
Transitive dependencies:
* cfgv -- imported over:
deptry/dependency_getter/base.py:13:11
For more information, see the documentation: https://fpgmaas.github.io/deptry/
I must say that I like the idea of using a format similar to what flake8
/Ruff
use, since it's pretty common on popular other tools too.
For instance, on mypy
:
deptry/config.py:14: error: Function is missing a type annotation for one or more arguments [no-untyped-def]
tests/test_config.py:57: error: "read_configuration_from_pyproject_toml" does not return a value [func-returns-value]
Found 2 errors in 2 files (checked 66 source files)
Going with this format would probably require to rethink a bit how we report the issues in the JSON output (by using error codes as well) if we were to go with this format though.
Let me know if this is something that makes sense, and which format you think is a better option (including some outside of the proposals). I already have a branch ready for the implementation, that I could adapt depending on the format we decide to go with.
I really like the proposal and I agree with you that it would be great to use a format similar to what flake8/Ruff use. One caveat though; how do we deal with obsolete dependencies? I guess for those we would display the specific line in pyproject.toml
or requirements.txt
where the dependency was added? This is not something we currently store somewhere, so we would have to add that information to the Dependency
object.
e.g.
pyproject.toml:13:11: DEP001 `hello` is obsolete; it is listed as a dependency but it is never imported
I really like the proposal and I agree with you that it would be great to use a format similar to what flake8/Ruff use. One caveat though; how do we deal with obsolete dependencies? I guess for those we would display the specific line in
pyproject.toml
orrequirements.txt
where the dependency was added? This is not something we currently store somewhere, so we would have to add that information to theDependency
object.e.g.
pyproject.toml:13:11: DEP001 `hello` is obsolete; it is listed as a dependency but it is never imported
Yeah, I'm not sure that we have the ability to retrieve the line/column in all cases for obsolete dependencies (pyproject.toml
format + requirements.txt
format), but having at least the file without the line/columns might be an ok tradeoff.
I'll see if we can have everything we need, as it would be ideal, otherwise I think we could live with not having the line/column for this specific case.
but having at least the file without the line/columns might be an ok tradeoff.
Completely agree!