Skip to content

[FEATURE]: ty + ruff lsp rather than pyright #5345

Closed as not planned
Closed as not planned

Description

@vlashada

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The ty lsp is starting to get a lot better and is so much faster than pyright which can allow us to run the lsp much more liberally for large code bases. It would be great if there was an option to select if we want to use pyright or ty!

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Dec 10, 2025
  2. rekram1-node commented on Dec 10, 2025

    @rekram1-node
    Collaborator

    Yeah I was thinking about this.

  3. rekram1-node commented on Dec 10, 2025

    @rekram1-node
    Collaborator

    I haven't touched python much is ty out of beta yet? Would it be a sane default yet? The speed is something that'd be rlly good

  4. vlashada commented on Dec 11, 2025

    @vlashada
    Author

    It is quite stable and mostly on par with pyright in terms of correctness, but it is technically still in alpha (although very close to beta). I think pyright should probably be the default for a few more weeks/months, but it would be nice to allow people to switch to ty since it is basically ready for production

  5. rekram1-node commented on Dec 11, 2025

    @rekram1-node
    Collaborator

    if u (or anyone else) is up to id accept a pr w an opencode experimental flag for lsp ty and then it should disable pyright, ty should only run if the flag is set

  6. rekram1-node commented on Dec 11, 2025

    @rekram1-node
    Collaborator

    flag.ts, lsp.ts relevant files i think its called lsp.ts or its lsp/server.ts

  7. debjan commented on Dec 11, 2025

    @debjan

    it can be added as custom lsp in settings, although I can't see the the point, as ruff is the way to go for llm interaction imho

  8. OpeOginni commented on Dec 15, 2025

    @OpeOginni
    Contributor

    @rekram1-node Taking a look at this, ways to install the lsp is either with brew, or like pip, to go with pip we have to make a venv and call the binary from there. Which of these approach you think is best?

  9. rekram1-node commented on Dec 15, 2025

    @rekram1-node
    Collaborator

    @OpeOginni prolly best to not auto install it, should use it if it exists instead

  10. OpeOginni commented on Dec 15, 2025

    @OpeOginni
    Contributor

    @rekram1-node thanks, Let me know what you think

  11. ajanvrin commented on Jan 8, 2026

    @ajanvrin

    My two bits on this (Python has been my primary language for a decade):

    The Python ecosystem is complicated, confusing and fragmented.

    It's not OpenCode's place to knight such or such LSP server as the "One supported LSP server".
    IMHO it's best to not try to install one, and to support all the LSP servers that are available (already installed).

    I'd remove the experimental check and run ty if it's installed, pyright if it's installed, and ruff if it's installed.

    It's up to the Python dev to know which he wants to use, and handle potential conflicts.

    Ruff and Ty are supposed to be running together for now (see astral-sh/ty-vscode#204), so that's what I make available in my environment (via custom LSP config in opencode.jsonc)

    The next best thing would be:

    1. Detect whether any supported LSP is available, if yes, run that
    2. If no LSP are found, automatically add ty and ruff as project dev dependencies and run that

    But it's not really necessary, it's ok to just run whatever is available.

  12. changed the title [-][FEATURE]: ty lsp rather than pyright[/-] [+][FEATURE]: ty + ruff lsp rather than pyright[/+] on Jan 17, 2026
  13. aliefe04 commented on Mar 23, 2026

    @aliefe04

    Adding my +1 to this with a specific pain point:

    Pylance/pyright causes significant CPU usage especially in larger Python projects. On my machine, I've noticed the language server consuming high CPU even during idle periods, which impacts the overall development experience.

    Why ruff would be better:

    • Much lighter weight - ruff is written in Rust and is significantly faster
    • Lower memory footprint - important for long coding sessions
    • Faster startup - nearly instant compared to pylance's initialization time
    • Same diagnostics - ruff covers most of what we need (linting, formatting, some type hints)

    Broader Proposal: Configurable LSP per language

    Rather than just swapping pyright for ruff, I think OpenCode should allow users to configure any LSP for any language via `opencode.json`:

    ```json
    {
    "lsp": {
    "python": "ruff",
    "typescript": "biome",
    "go": "gopls",
    "rust": "rust-analyzer"
    }
    }
    ```

    This would:

    • Let users choose lighter alternatives when performance matters
    • Support project-specific tooling (e.g., basedpyright vs pyright)
    • Align with how formatters are already configurable
    • Give power users full control over their LSP experience

    This is somewhat related to #9472 but I wanted to emphasize the performance/CPU angle as a key motivator.

  14. debjan commented on Mar 23, 2026

    @debjan

    @aliefe04 it is already possible:

    {  
      "lsp": {
        "ruff": {
          "command": ["ruff", "server"],
          "extensions": [".py"]
        },
        "ty": {
          "command": ["ty", "server"],
          "extensions": [".py"]
        },
        "pyright": {
          "disabled": true
        }
      }
    }
  15. added a commit that references this issue on Mar 23, 2026
  16. removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on May 3, 2026
  17. github-actions commented on Jul 3, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions