You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There are valid reasons to ignore some issues that are reported. For instance, a dependency can legitimately be reported as obsolete, although the dependency is not directly used in the codebase, but used as a CLI (for instance, a webserver). Another case could be a dev dependency that is conditionally imported in production code, to make sure this is only done in a dev environment.
While for the first case, ignoring the dependency entirely is probably enough, for the second one, ignoring the dependency entirely could hide issues in other files, that would not be legitimate.
Describe the solution you would like
It would be nice to be able to only ignore issues in specific files, and/or on specific lines. Many popular code quality tools already provide this option, such as flake8, mypy, ruff, isort, or bandit.
Ignoring specific files
In order to ignore specific files, --ignore_* options (such as --ignore_missing, and its ignore_missing counterpart in pyproject.toml), or any new option we introduce, could be specified as a dict[str, list[Path] to only ignore a dependency in specific locations, instead of a list[str] that only allows to ignore a dependency entirely.
If we were to introduce this change, we should still be able to ignore dependencies entirely, regardless of the locations, as there still are valid reasons to want that.
Since we probably can't mix the ability to ignore a dependency for all files and the ability to ignore a dependency for specific lines, it might be required to provide one or multiple new options.
Ignoring specific lines
In addition to ignoring specific lines, or independently of the implementation of the other option, we could add the ability to only ignore specific lines in a file, to be even more precise on the exclusion.
# Ignoring a specific issueimporttomllib# deptry: ignore[missing]# orimporttomllib# deptry: ignore[DEP001]# Ignoring multiple issuesimporttomllib, ujson# deptry: ignore[missing,transitive]# Ignoring all potential issuesimporttomllib, ujson# deptry: ignore
Obsolete dependencies
It might make less sense to be able to ignore obsolete dependencies, since they are usually defined in one dependency specification file, and it's probably enough to ignore a dependency entirely, but it might not hurt to be able to handle comments as well, if we are able to parse them when parsing the dependencies.
The text was updated successfully, but these errors were encountered:
Great idea, I think this would be very useful! Given #398, it might make sense to implement this similar to ruff as well. ruff has the following flags:
--ignore <RULE_CODE>
Comma-separated list of rule codes to disable
--per-file-ignores <PER_FILE_IGNORES>
List of mappings from file pattern to code to exclude
In our case, we could have the following flags:
--ignore
--per-rule-ignores
--per-file-ignores
--ignore can be used to ignore a rule (DEP001, DEP002, etc) in the entire codebase. e.g.
deptry . --ignore DEP001,DEP002
--per-rule-ignores can be used to skip certain packages or modules for specific rules, e.g: Ignore matplotlib for DEP002.
The --per-file-ignores can be used to skip checking for specific rules for specific files. Here, we might want to give functionality to both ignore a rule completely per file, and only ignore it for specific modules/dependencies:
@fpgmaas I think a good part of this issue was addressed in 0.12.0. Have the in-file import tomllib # deptry: ignore[DEP001]
style ignores already been added as well or is that still outstanding?
Is your feature request related to a problem? Please describe.
There are valid reasons to ignore some issues that are reported. For instance, a dependency can legitimately be reported as obsolete, although the dependency is not directly used in the codebase, but used as a CLI (for instance, a webserver). Another case could be a dev dependency that is conditionally imported in production code, to make sure this is only done in a dev environment.
While for the first case, ignoring the dependency entirely is probably enough, for the second one, ignoring the dependency entirely could hide issues in other files, that would not be legitimate.
Describe the solution you would like
It would be nice to be able to only ignore issues in specific files, and/or on specific lines. Many popular code quality tools already provide this option, such as flake8, mypy, ruff, isort, or bandit.
Ignoring specific files
In order to ignore specific files,
--ignore_*
options (such as--ignore_missing
, and itsignore_missing
counterpart inpyproject.toml
), or any new option we introduce, could be specified as adict[str, list[Path]
to only ignore a dependency in specific locations, instead of alist[str]
that only allows to ignore a dependency entirely.In
pyproject.toml
, this would be something like:On the command line, we could re-use the format introduced by
--package-module-name-map
:Retro-compatibility
If we were to introduce this change, we should still be able to ignore dependencies entirely, regardless of the locations, as there still are valid reasons to want that.
Since we probably can't mix the ability to ignore a dependency for all files and the ability to ignore a dependency for specific lines, it might be required to provide one or multiple new options.
Ignoring specific lines
In addition to ignoring specific lines, or independently of the implementation of the other option, we could add the ability to only ignore specific lines in a file, to be even more precise on the exclusion.
We could go with a solution similar to https://flake8.pycqa.org/en/6.0.0/user/violations.html#in-line-ignoring-errors, https://pycqa.github.io/isort/docs/configuration/action_comments.html#isort-skip, or https://mypy.readthedocs.io/en/stable/type_inference_and_annotations.html#silencing-type-errors, by having something like:
Obsolete dependencies
It might make less sense to be able to ignore obsolete dependencies, since they are usually defined in one dependency specification file, and it's probably enough to ignore a dependency entirely, but it might not hurt to be able to handle comments as well, if we are able to parse them when parsing the dependencies.
The text was updated successfully, but these errors were encountered: