Skip to content

Conversation

@AlexWaygood
Copy link
Member

Summary

It's currently pretty painful to have ty's workspace diagnostics enabled in the Ruff repo, because ty will proceed to type-check every single fixture in the ruff_linter crate, resulting in >10,000 diagnostics. This PR disables ty workspace diagnostics if you're browsing this repo inside VSCode.

Test Plan

On this branch, I no longer have >10,000 diagnostics reported in the problems tab in VSCode, despite having the ty-vscode plugin installed and despite having this setting in my VSCode user settings:

    "ty.diagnosticMode": "workspace"

@AlexWaygood AlexWaygood added the internal An internal refactor or improvement label Nov 24, 2025
@Gankra
Copy link
Contributor

Gankra commented Nov 24, 2025

To be clear you specifically have workspace diagnostics custom-enabled in your vscode, and this is "and it sucks that i did, in this project in particular"?

@AlexWaygood
Copy link
Member Author

To be clear you specifically have workspace diagnostics custom-enabled in your vscode, and this is "and it sucks that i did, in this project in particular"?

yeah, kinda:

  1. I want workspace diagnostics enabled for all my Python projects, so I enabled that in my user settings, and it was great, I love it
  2. But then I opened up Ruff and hoo boy, I cannot deal with that many diagnostics in the problem tab
  3. So I went to disable it in the workspace settings for Ruff, and that was nice, now I have workspace diagnostics enabled for all my Python projects but not for this one special project (Ruff) that isn't really a Python project but happens to have literally thousands of lines of Python that happen to be deliberately of questionable quality
  4. But oh no, now I can't do git commit -am anymore because Ruff apparently commits .vscode/settings.json into source control for some reason rather than .gitignoring it. So PR'ing it up (as I'm doing here) is the only solution here, it seems?

@Gankra
Copy link
Contributor

Gankra commented Nov 24, 2025

but happens to have literally thousands of lines of Python that happen to be deliberately of questionable quality

Well that seems as good a reason as any, ship it

@AlexWaygood AlexWaygood merged commit d379f38 into main Nov 24, 2025
37 checks passed
@AlexWaygood AlexWaygood deleted the alex/ty-workspace-settings branch November 24, 2025 20:06
carljm added a commit to mtshiba/ruff that referenced this pull request Nov 25, 2025
* main:
  [ty] Extend Liskov checks to also cover classmethods and staticmethods (astral-sh#21598)
  Dogfood ty on the `scripts` directory (astral-sh#21617)
  [ty] support generic aliases in `type[...]`, like `type[C[int]]` (astral-sh#21552)
  [ty] Retain the function-like-ness of `Callable` types when binding `self` (astral-sh#21614)
  [ty] Distinguish "unconstrained" from "constrained to any type" (astral-sh#21539)
  Disable ty workspace diagnostics for VSCode users (astral-sh#21620)
  [ty] Double click to insert inlay hint (astral-sh#21600)
  [ty] Switch the error code from `unresolved-attribute` to `possibly-missing-attribute` for submodules that may not be available (astral-sh#21618)
  [ty] Substitute for `typing.Self` when checking protocol members (astral-sh#21569)
  [ty] Don't suggest things that aren't subclasses of `BaseException` after `raise`
  [ty] Add hint about resolved Python version when a user attempts to import a member added on a newer version (astral-sh#21615)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

internal An internal refactor or improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants