Skip to content

Conversation

@Gankra
Copy link
Contributor

@Gankra Gankra commented Oct 23, 2025

This introduces a safe_mode to our settings type that tells our initialization code to more aggressively believe Settings Failure Is Not An Error. This allows the full settings initialization logic to be used as much as possible for the default database while trying to keep any discarded results as narrow as possible for graceful degradation.

Finally, Python has SFINAE.

Fixes astral-sh/ty#859

This introduces a safe_mode to our settings type that tells our initialization code
to more aggressively believe Settings Failure Is Not An Error. This allows the full
settings initialization logic to be used as much as possible for the default database
while trying to keep any discarded results as narrow as possible for graceful degradation.

Finally, Python has SFINAE.
@Gankra Gankra added server Related to the LSP server ty Multi-file analysis & type inference labels Oct 23, 2025
@github-actions
Copy link
Contributor

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

@github-actions
Copy link
Contributor

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

@Gankra
Copy link
Contributor Author

Gankra commented Oct 23, 2025

Ah, rude. The exact case of VIRTUAL_ENV=gibberish actually blows up in asserts in dynamic_resolution_paths. This is a big ol' game of whackamole.

@Gankra
Copy link
Contributor Author

Gankra commented Oct 23, 2025

The failure with a gibberish VIRTUAL_ENV is a fascinating maybe-independent bug in our handling of symlinked python environments (homebrew).

We actually handle the gibberish VIRTUAL_ENV value gracefully but then we fallback to grabbing a reference to some homebrew site-packages and then blowup because symlinks are happening and the same dir looks like two different dirs.

(just on main, not with my patches, although my patches don't affect this):

No root found for path '/opt/homebrew/Cellar/python@3.13/3.13.5/lib/python3.13/site-packages'. Known roots: FileRoots(
...
path: "/opt/homebrew/Cellar/python@3.13/3.13.5/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages",

Here we have a symlink:

/opt/homebrew/Cellar/python@3.13/3.13.5/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages 
-> 
../../../../../../lib/python3.13/site-packages

@sharkdp sharkdp marked this pull request as ready for review October 23, 2025 19:06
@MichaReiser

This comment was marked as resolved.

@sharkdp

This comment was marked as resolved.

@AlexWaygood AlexWaygood marked this pull request as draft October 23, 2025 19:24
@MichaReiser
Copy link
Member

You mentioned over chat if we should return a Result with the errors instead of a safe flag. I'm starting to see the appeal of this, if we try to get as much right as possible even in safe mode

The resolution methods could return a result where the error type wraps the fallback settings and the first (or all errors). A caller could then decide to build the program with the fallback settings (or error).

I'm not sure how much harder that is

@Gankra
Copy link
Contributor Author

Gankra commented Oct 30, 2025

We no longer have an input that crashes the default server so I'm going to close this as WONTFIX until someone reports a new one.

@Gankra Gankra closed this Oct 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

server Related to the LSP server ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Server panics if ProgramSettings of default database aren't invalid

4 participants