Eagerly validate typeshed versions

[MichaReiser]

Summary

This should be the last PR in the module resolver validation stack.

It makes the typeshed version file parsing eagerly by moving it into SearchPaths::from_settings. This allows us to exit Red Knot early if the VERSIONS file is missing or incorrect. I added custom logic to the file watching to handle changes to the VERSIONS file (and added a test for it).

Handling changes to the VERSIONS file introduces some complexity because Program::update_search_paths takes a SearchPathSettings struct but we no longer know the SearchPathSettings in apply_changes.

A possible solution to this problem is to expose a method Program::reload_versions_file instead, which would do the trick just fine. However, I disliked that it is very low-level. We may have other cases where we need to reload the search-path settings, and I want to avoid introducing special case methods for each of those.

That's why I started looking into how we want to support configurations. What we need in apply_changes is access to what the user configured. The approach follows the same as Ruff's:

• *Configuration: The configuration that uses Option in most places to know whether the user provided a value or not. Configurations from different sources can be merged (e.g. CLI overrides the pyproject.toml configuration)
• *Settings: A resolved configuration in the sense that Red Knot fills in default values and e.g. merges values from different configurations (resolves the target-python version).

This PR does not add support for loading or deserializing configurations. It just builds out some of the infrastructure.

Test Plan

cargo test

cargo run -q --bin red_knot -- --current-directory=../test -v --custom-typeshed-dir ./blaaa
INFO Target version: 3.8
Red Knot failed
  Cause: Invalid search path settings
  Cause: Failed to read the custom typeshed versions file '/home/micha/astral/test/blaaa/stdlib/VERSIONS': No such file or directory (os error 2)

[MichaReiser]

An alternative to storing typeshed_versions on SearchPaths would be to store the TypeshedVersions alongside the SearchPath (for the Custom or vendored stdlib variants). I don't really have an opinion on what's better. Let me know if you have ;)

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[AlexWaygood]

If I understand correctly, this PR appears to treat the VERSIONS file as something that we can parse once upfront, and never parse again. That's true if we're using a vendored typeshed, but not if we're using a custom typeshed. The user might edit the VERSIONS file in between two queries; we need to be able to react to that and re-parse the VERSIONS file if our cached version is stale. That's why it's a Salsa query on main.

[MichaReiser]

If I understand correctly, this PR appears to treat the VERSIONS file as something that we can parse once upfront, and never parse again. That's true if we're using a vendored typeshed, but not if we're using a custom typeshed. The user might edit the VERSIONS file in between two queries; we need to be able to react to that and re-parse the VERSIONS file if our cached version is stale. That's why it's a Salsa query on main.

Hmm I missed this point. I have to add some manual file-watching to trigger a reload in this case. It also forces us to explicitly think about what should happen if parsing the VERSION files fails when we were able to parse it successfully before (in watch mode)

[codspeed-hq]

CodSpeed Performance Report

Merging #12786 will degrade performances by 6.56%

_{Comparing eagerly-resolve-typeshed-versions (ba1a840) with main (f873d2a)}

Summary

❌ 1 regressions
✅ 31 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	eagerly-resolve-typeshed-versions	Change
❌	linter/all-rules[numpy/globals.py]	726.4 µs	777.3 µs	-6.56%

[MichaReiser]

We may want to store the entire WorkspaceSettings on Workspace long term but it isn't clear to me if we actually want to do this. That's why I went with storing the absolute minimum

[carljm]

I skimmed this and it looks reasonable to me, but I'd rather have @AlexWaygood take a look.

[MichaReiser]

I plan to merge this tomorrow afternoon.

[AlexWaygood]

Looks fantastic. Thanks for working on this, and sorry for the slow review!

[MichaReiser]

Uff, rebasing this PR after so long is painful