Feat: detect changes also in configuration files

[mikeleppane]

Detect changes also in configuration files. Detected config files are: pyproject.toml, ruff.toml,.ruff.toml

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.03     19.4±0.47ms     2.1 MB/sec    1.00     18.8±0.45ms     2.2 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.04      4.6±0.23ms     3.6 MB/sec    1.00      4.4±0.12ms     3.8 MB/sec
linter/all-rules/numpy/globals.py          1.02   552.8±19.44µs     5.3 MB/sec    1.00   543.8±13.65µs     5.4 MB/sec
linter/all-rules/pydantic/types.py         1.04      8.0±0.36ms     3.2 MB/sec    1.00      7.7±0.25ms     3.3 MB/sec
linter/default-rules/large/dataset.py      1.04      9.3±0.28ms     4.4 MB/sec    1.00      9.0±0.42ms     4.5 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.05  1992.2±70.52µs     8.4 MB/sec    1.00  1895.0±45.30µs     8.8 MB/sec
linter/default-rules/numpy/globals.py      1.00    224.4±9.69µs    13.1 MB/sec    1.02   228.8±17.89µs    12.9 MB/sec
linter/default-rules/pydantic/types.py     1.03      4.1±0.15ms     6.2 MB/sec    1.00      4.0±0.08ms     6.4 MB/sec
parser/large/dataset.py                    1.03      7.5±0.21ms     5.4 MB/sec    1.00      7.3±0.11ms     5.6 MB/sec
parser/numpy/ctypeslib.py                  1.04  1488.1±89.71µs    11.2 MB/sec    1.00  1427.0±73.31µs    11.7 MB/sec
parser/numpy/globals.py                    1.00    141.7±7.21µs    20.8 MB/sec    1.01   142.6±10.78µs    20.7 MB/sec
parser/pydantic/types.py                   1.02      3.2±0.10ms     8.0 MB/sec    1.00      3.1±0.09ms     8.2 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     16.1±0.11ms     2.5 MB/sec    1.00     16.0±0.09ms     2.5 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.1±0.04ms     4.1 MB/sec    1.00      4.1±0.05ms     4.1 MB/sec
linter/all-rules/numpy/globals.py          1.00   485.0±10.56µs     6.1 MB/sec    1.00    484.6±6.42µs     6.1 MB/sec
linter/all-rules/pydantic/types.py         1.00      6.8±0.05ms     3.7 MB/sec    1.00      6.8±0.05ms     3.8 MB/sec
linter/default-rules/large/dataset.py      1.00      8.2±0.05ms     5.0 MB/sec    1.00      8.2±0.04ms     5.0 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00  1726.5±14.93µs     9.6 MB/sec    1.00  1725.1±15.37µs     9.7 MB/sec
linter/default-rules/numpy/globals.py      1.00    191.6±2.89µs    15.4 MB/sec    1.02    196.3±8.04µs    15.0 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.7±0.03ms     7.0 MB/sec    1.01      3.7±0.09ms     6.9 MB/sec
parser/large/dataset.py                    1.00      6.7±0.06ms     6.1 MB/sec    1.01      6.7±0.05ms     6.1 MB/sec
parser/numpy/ctypeslib.py                  1.00  1265.3±15.28µs    13.2 MB/sec    1.01  1275.2±15.47µs    13.1 MB/sec
parser/numpy/globals.py                    1.00    128.9±2.00µs    22.9 MB/sec    1.00    129.5±1.82µs    22.8 MB/sec
parser/pydantic/types.py                   1.00      2.8±0.03ms     9.1 MB/sec    1.01      2.8±0.03ms     9.0 MB/sec

[MichaReiser]

I think we have to recompute most of the variables defined above starting from line 115 whenever a pyproject.toml changes. For example, you can configure the output format in the settings and we should respect that change if we support reloading configuration files.

[mikeleppane]

Absolutely! Is there now something more to be recalculated other than pyproject_strategy?

[MichaReiser]

I'm not too familiar with that code. A safe assumption would be to re-compute everything that is derived from the pyproject_strategy (all settings that are supported in the configuration and aren't CLI options only). I wonder if we even have to be clever about it or if we can simply call check again. The main challenge that I see with that approach is that we might mess up the printer output because watch uses write_continuously

[MichaReiser]

Nit: I recommend matching on the extension or file name explicitly. E.g. we don't want to match a file named py

Suggested change

	if let (Some(file_name), Some(suffix)) = (path.file_name(), path.extension()) {
	if let (Some(file_name), Some(suffix)) = (file_name.to_str(), suffix.to_str()) {
	if WATCHED_FILES.contains(&file_name) || WATCHED_FILES.contains(&suffix) {
	return true;
	}
	}
	}
	if matches!(path.file_name(), Some("pyproject.toml" | "ruff.toml" |".ruff.toml")) {
	true
	} else if matches!(path.extension(), Some("py" | "pyi")) {
	true
	} else { false }

[mikeleppane]

Good catch!

[MichaReiser]

Making this configurable seems overkill for now. I would prefer matching statically on the file name and extension. That should also allow the compiler to optimize the code better (see my original comment on how to implement it with a match).

[MichaReiser]

We can keep this a standalone function and instead introduce a new tri-boolean type to signal whether to ignore the change, it's a python file, or a configuration change

#[derive(Copy, Clone, Debug, Eq, PartialEq)]
enum ChangeKind {
	Configuration,
	SourceFile,
	Ignore
}

fn detect_change(paths: &[PathBuf]) -> ChangeKind {
	...
}

[MichaReiser]

Only re-computing the pyproject_strategy, is, unfortunately, not sufficient. There are multiple derived variables on line 107-185 that need to be recomputed too

[charliermarsh]

I added a TODO for this.