lint-configuration-valid (TN007)#
Group |
Default severity |
|---|---|
Structural |
Warning |
A technote can switch a rule off for itself, in the [technote.lint] ignore list of its technote.toml or with --ignore on the command line (see Ignoring a rule).
This rule reports an ignore entry the linter cannot act on: a code that no rule carries.
The shape of the file’s table — that ignore is an array of strings, each an uppercase prefix and a number — is validated by the technote package when it reads technote.toml, and a violation is reported as TN001 instead; a mistyped --ignore on the command line, which technote never sees, is reported here.
The point is that a mistake here is silent otherwise.
A technote that lists TN150 believes a rule is off; the rule it meant to name goes on firing, and nothing says why.
TN007 turns that into a finding, and the run continues with whichever entries are valid — one bad entry never switches off the rest of the list, and never stops the lint run.
Example of a failing technote#
[technote.lint]
ignore = ["TN150"]
[TN007] 'TN150' in technote.toml [technote.lint] is not a lint rule code, so no rule is ignored for it.
An ignore written as a bare string rather than an array is a schema violation, and technote reports it before the linter’s rules run:
[technote.lint]
ignore = "TN105"
[TN001] technote.toml does not conform to the schema: ... technote.lint.ignore ...
The same TN007 message reports a mistyped --ignore on the command line, naming --ignore as the source instead of the file.
How to fix it#
Check the code against the rule table, which lists every code the linter knows, and write the list as an array of strings:
[technote.lint]
# Zenodo DOI minted in 2016; a Rubin release cannot update its metadata.
ignore = ["TN105"]
In the file a code is written in uppercase, as the rule table lists it; --ignore tn105 on the command line names the same rule as TN105.
Each entry should be commented with why the rule is off, since the next person to read the file cannot tell an unfixable finding from an unfixed one.
This rule is a warning: a configuration mistake does not fail a lint run on its own, though --strict promotes it like any other warning.
See also#
Ignoring a rule — how to switch a rule off for one technote, and when that is the right answer.
TN105 — the DataCite cross-check, the rule most likely to need ignoring, for a DOI whose registered record cannot be changed.