zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
45.45k stars 2.48k forks source link

Python lsp: Pyright isn't good #7296

Open lctzz540 opened 6 months ago

lctzz540 commented 6 months ago

Check for existing issues

Describe the feature

it should be pylsp. The pyright has issues about recognize libraries installed

If applicable, add mockups / screenshots to help present your vision of the feature

No response

JosephTLyons commented 6 months ago

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

plattenschieber commented 6 months ago

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

Indeed they did build a language server protocol for Ruff already ruff-lsp @JosephTLyons 🔥

JosephTLyons commented 6 months ago

Yeah, pyright has been a big source of pain for us in the Zed-Python intersection. I think we should def swap out to something better. I've not heard of pylsp, but we should def add it to the list of ones to check out:

We are working on language plugins at the moment, so, in the not-so-distant future, someone can just add these servers as plugins, but I do think we should swap out our provided one for a bettter one.

Indeed they did build a language server protocol for Ruff already ruff-lsp @JosephTLyons 🔥

AFAICT, ruff-lsp only support formatting and linting as of right now, as they haven't gotten to building things out like go to def and auto-completion, but I read they will be doing that at some point.

failable commented 5 months ago

https://github.com/pappasam/jedi-language-server

JacobGoldenArt commented 5 months ago

Yeah. I love Zed but when I open a Python project it's just strange. I will activate my .venv in my project directory and the script will run but when you look at the python file the imports are all red and can't be resolved.

Screenshot 2024-03-02 at 7 58 28 PM
JacobGoldenArt commented 5 months ago

See that python-dotenv is installed, along with pydantic in my env - (pip list) but I guess pyright is not checking for packages in the project-directory/.venv ???

failable commented 5 months ago

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}
Moshyfawn commented 5 months ago

There's an issue #8541 about resolving modules with Pyright.

newtome8888 commented 5 months ago

I see this problem last for months, but there's still no real solution?

JosephTLyons commented 5 months ago

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

This should actually solve the problem - for some reason, during the migration of our documentation, we lost our Python docs that mentions this config file. I've quickly dumped the old Python docs contents into the configuration section of our website, here. I need to bring back more documentation, so I will organize this better later on.

As a side note, I want to say that we are going to be doing more for Python here shortly - we recognize just how important this language is, being one of the top most-used languages, and we want to improve for Python devs in Zed.

newtome8888 commented 5 months ago

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

This should actually solve the problem - for some reason, during the migration of our documentation, we lost our Python docs that mentions this config file. I've quickly dumped the old Python docs contents into the configuration section of our website, here. I need to bring back more documentation, so I will organize this better later on.

As a side note, I want to say that we are going to be doing more for Python here shortly - we recognize just how important this language is, being one of the top most-used languages, and we want to improve for Python devs in Zed.

I tried it, but no luck. I use poetry in my python project, does it matter? 2024-03-04_23-04-32

collinsinclair commented 5 months ago

To add to the corpus of Pyright issues, in is_24hour = models.BooleanField(default=False), False is red-underlined for

Argument of type "Literal[False]" cannot be assigned to parameter "default" of type "type[NOT_PROVIDED]" in function "__init__" Type "Literal[False]" cannot be assigned to type "type[NOT_PROVIDED]"

Additionally, in def __str__(self):, __str__ is red-underlined for

Method "__str__" overrides class "Model" in an incompatible manner Return type mismatch: base method returns type "str", override returns type "CharField" "CharField" is incompatible with "str"

I have done no custom configuration. I believe these shouldn't be showing issues as they work as expected and are standard practices.

r-cha commented 5 months ago

I tried it, but no luck. I use poetry in my python project, does it matter?

@newtome8888 run poetry env info to find the path to your virtualenv, then add that to your pyrightconfig. Worth noting, this path will be different per machine, so don't add pyrightconfig.json to any version control. Mine looks something like this:

{
  "venvPath": "/Users/username/Library/Caches/pypoetry/virtualenvs",
  "venv": "projectname-p0LYZhue-py3.11"
}
JosephTLyons commented 5 months ago

I tried it, but no luck. I use poetry in my python project, does it matter?

@newtome8888 run poetry env info to find the path to your virtualenv, then add that to your pyrightconfig. Worth noting, this path will be different per machine, so don't add pyrightconfig.json to any version control. Mine looks something like this:

{
  "venvPath": "/Users/username/Library/Caches/pypoetry/virtualenvs",
  "venv": "projectname-p0LYZhue-py3.11"
}

Just to mention, there is a setting in poetry tells poetry to install the venv within the project:

Which would stabilize where the pyrightconfig.json points to, when running the project on multiple machines.

failable commented 5 months ago

Using pyright is literally painful.

myusuf3 commented 5 months ago

To add to the corpus of Pyright issues, in is_24hour = models.BooleanField(default=False), False is red-underlined for

Argument of type "Literal[False]" cannot be assigned to parameter "default" of type "type[NOT_PROVIDED]" in function "init" Type "Literal[False]" cannot be assigned to type "type[NOT_PROVIDED]"

Additionally, in def __str__(self):, __str__ is red-underlined for

Method "str" overrides class "Model" in an incompatible manner Return type mismatch: base method returns type "str", override returns type "CharField" "CharField" is incompatible with "str"

I have done no custom configuration. I believe these shouldn't be showing issues as they work as expected and are standard practices.

I am running into the same issue. it's hurting more than its helping.

strangemonad commented 5 months ago

@JosephTLyons I'd like to offer a counter proposal - pyright is actually really good... assuming it gets pointed to the right thing. Expanding on https://github.com/zed-industries/zed/issues/7808#issuecomment-2012710492

1) Putting aside the config / invocation of pyright for a moment, I believe the approach to how the type system was implemented in the pyright type-checker leads to the best editor experience. There's a few subtle choices e.g. how bi-directly type inference within a method with partial type annotations are handled compared to mypy that make a much better dev experience while editing python code. It's also faster than mypy and more complete than any other option currently available in my experience.

2) robustly invoking pyright is the key. I think the docs are clunky but the most robust approach effectively boils down to the following

pyright --pythonpath $ABS_PATH_TO_PYTHON --project $ABS_PATH_TO_PROJECT_ROOT

For example, if I have a workspace pointed at the following folders

api
    - pyproject.toml # poetry project
    - src/
    - tests/
backend
    - pyproject.toml # poetry project
    - src/
    - tests/
frontend
    - yarn / node...

To get pyright working for backend I would do cd backend && pyright --pythonpath $(poetry env info --executable) --project $PWD

Why not use the venv venvPath options? If you scrutinize the pyright docs, they mention that this isn't really scalable because it's hard to enforce that every dev creates a venv in the same location by default. The pythonpath option is how vscode invokes the pyright lsp.

Why not use the execution environments option? In practice, while you can have a pyright config file in the project root, you might want to open multiple different folders in a single editor workspace.

Yevgnen commented 5 months ago

@strangemonad Can you share the "actually really good" parts? I don't really get it...

strangemonad commented 5 months ago

@Yevgnen sure, I can give it a shot. I think it's helpful to break this up into a few categories:

everything below being said I do think the ease of use of pyright could be improved. I'd also like to remind folks that even though pyright comes out of Microsoft, for reasons I don't understand it's primarily the work of only a single person - including documentation and triaging of bugs

  1. choice of LSP
  2. LSP vs type checker vs linter
  3. Speed
  4. PyRight's type system

1 I'm still very much in favor of user choice of LSP. Folks should be able to pick what's currently best at their current project's needs. I primarily do python work in a single editor workspace that contains many python projects in various workspace directors (e.g. VSCode's add folder to workspace). Most of these are CLIs, services, or ML model pipelines. This is probably pretty different than the needs of someone who works on, say, a single python open source library at a time.

2 There might be some LSPs that work separately from a downstream type checker. Personally, I like a couple invariants a) I want anything that would fail a type checking command or lint command to show up inline (red / yellow squiggles) as I'm writing the code. b) I don't find it personally acceptable if symbol completion suggests something that's not a valid symbol and I end up getting method not found or what not when I run the code I practice, that pretty much means that whatever the LSP is calling out to needs to be equivalent to the same type checker implementation. E.g. if someone were able to make a better python LSP front end that called out to pyright + ruff and combined results, that would be great (assuming they could get it working reliably which would be no small feat given the current state of the world).

Speed Once PyRight is up and running, responses and updates feel faster to me than other approaches. I don't have empirical evidence for this, just what it feels like to me.

Type system This is probably the most nuanced but I think it makes a big difference, especially around producing false-negatives and suggesting type hint corrections while typing. Some back context: As type hints have been gradually added to Python it's been done differently than other languages that have added progressive optional typing (e.g. typescript). Effectively, when taken together, the various python type hint PEPs don't really define a type system, but rather provide the guidelines and specifications for a possible type system. Rather than talk about the "python type system" it would probably be more correct to say that MyPy, Pyright, pytypre, pyre have each implemented "a python type system" with different design constraints to suit specific needs. I'd consider MyPy and PyRight to be the 2 most general implementations. Pytype has made choices that make it more applicable to Google's large (and older) python code base. Pyre has learned a lot from flowtype but is aimed a bit more at finding security vulnerabilities.

Putting aside the speed difference between pyright and mypy, there's a bunch of subtle design differences that might seem insignificant but I think end up mattering a lot when editing code. To boil it down to just 2:

1) How missing type hints are handled 2) Limited-scope type inference.

MyPy interprets the PEP quite literally. e.g. if a function has no return type hint, pyright treats it as if it had the Any return type. Pyright, however treat's it as "untyped" and then treats this "Untyped" fictitious type as being equivalent to Any.

Within bounded scopes (e.g. the scope of a method) pyright implements bi-direction type checking (in the style of Pierce) e.g. even though def foo(a, b): has no type hints, if the first line is a + b we know we at the very least expect a to implement __add__ all these bits of information within a method to either catch errors that can't be caught if you don't do type inference or suggest type hints for parameters or the return type.

geoqiao commented 4 months ago

Is it possible to add a global setting in Zed like pylance in vscode? It's really a pain to have to manually addpyrightconfig.json every time creating a Python project.https://github.com/zed-industries/zed/issues/10587

didibear commented 3 months ago

@geoqiao pyright can be configured in the pyproject.toml directly as documented here, for example like this:

[tool.pyright]
venv = ".venv"
venvPath = "."
geoqiao commented 3 months ago

@geoqiao pyright can be configured in the pyproject.toml directly as documented here, for example like this:


[tool.pyright]

venv = ".venv"

venvPath = "."

It still needs to be manually configured.

vladimir-sama commented 3 months ago
item_icon : Optional[FileStorage] = request.files.get('item_icon')
if item_icon:
  file_name : str = item_id + '.' + item_icon.filename.rsplit('.', 1)[1].lower()

Pyright: "rsplit" is not a known attribute of "None" Good typing system? It doesn't even do TypedDict correctly

So, will there be an option system or extensions soon? I'd like Pylance but I'm not sure if it can be an extension. I've tried MyPy, but cannot remember if it was good

tmke8 commented 3 months ago

I'd like Pylance but I'm not sure if it can be an extension.

Pylance is just pyright with a few small added features. Here is a list of differences: https://github.com/microsoft/pylance-release/issues/3838#issuecomment-1387510630

Pyright can definitely handle TypedDict. If you give more context, I can tell you what the problem is.

I agree that pyright is currently hard to set up with Zed. But with

[tool.pyright]
venvPath = "."
venv = ".venv"
# typeCheckingMode = "off"    # uncomment this if you don't want type checking

in my pyproject.toml and poetry configured with

poetry config virtualenvs.in-project true

it works very well.

injust commented 2 months ago
item_icon : Optional[FileStorage] = request.files.get('item_icon')
if item_icon:
  file_name : str = item_id + '.' + item_icon.filename.rsplit('.', 1)[1].lower()

Pyright: "rsplit" is not a known attribute of "None" Good typing system? It doesn't even do TypedDict correctly

Off-topic, but @vladimir-sama your example is simply user error: FileStorage.filename can be None. See https://github.com/pallets/werkzeug/blob/3.0.3/src/werkzeug/datastructures/file_storage.pyi#L12.

failable commented 2 months ago

Does Zed support to config pyright to make it work with workspaces?

jaanli commented 2 months ago

yes, i am also having this issue :(

yash-desai-naik commented 2 months ago

Just simply open the project form the terminal with env activated!!!

I faced the same issue when opening project directory directly in zed, pyright started to yell "missing libraries".

Solution:

  1. Open terminal
  2. cd YOUR_PROJECT_DIRECTORY
  3. source .venv/bin/activate
  4. zed .

now it should work smoothly

andre0xFF commented 2 months ago

Just simply open the project form the terminal with env activated!!!

I faced the same issue when opening project directory directly in zed, pyright started to yell "missing libraries".

Solution:

  1. Open terminal
  2. cd YOUR_PROJECT_DIRECTORY
  3. source .venv/bin/activate
  4. zed .

now it should work smoothly

doesn't work. activated the environment with poetry and still get unresolved imports.

geoqiao commented 2 months ago

Just simply open the project form the terminal with env activated!!!

I faced the same issue when opening project directory directly in zed, pyright started to yell "missing libraries".

Solution:

  1. Open terminal

  2. cd YOUR_PROJECT_DIRECTORY

  3. source .venv/bin/activate

  4. zed .

now it should work smoothly

doesn't work. activated the environment with poetry and still get unresolved imports.

This is a problem with pyright config, which has nothing to do with whether to activate the python virtual environment.

We need a better way to make pyright work without generating pyryghtconfig.json every time opening a new project.

Act0r1 commented 2 months ago

You need this file.

$ cat pyrightconfig.json
{
  "venvPath": ".",
  "venv": ".venv"
}

it is not solve problem tbh

KraXen72 commented 1 month ago

i'm using https://github.com/DetachHead/basedpyright in vscode and it's been great so far at replacing normal pyright or pylance. could be worth a shot.

bluekeybo commented 1 month ago

@JosephTLyons when will this be resolved? The python devs are suffering, in fact Zed is unusable until this is resolved. Seeing unresolved imports is a pain. Thanks!

FilipeBisinella commented 1 month ago

I made a PR to allow for pyright settings, which could help with this.

https://github.com/zed-industries/zed/pull/14265

jdoss commented 1 month ago

Is switched to https://github.com/DetachHead/basedpyright a bit a go in VSCode and it's been great. It should be a drop in replacement for pyright. ™️

Maybe make it so people can can choose between the two? One thing that is great about basedpyright is it is published as a pypi package so you can set the version you want inside of your python project.

https://docs.basedpyright.com/#/?id=published-as-a-pypi-package-no-nodejs-required

m1guer commented 1 month ago

placement

Hi, i have done one, but i cant test on linux(maybe a bug or skill issue), if you wanna test: https://github.com/m1guer/basedpyright-zed

failable commented 1 month ago

@m1guer How to use? I select the directory on "Install Dev Extension" and nothing happens.

m1guer commented 1 month ago

i fixed some bugs, maybe works now. try this in you zed settings:

{
  "languages": {
    "Python": {
     "language_servers":["!pyright","basedpyright"]
    }
  }
}
failable commented 1 month ago

@m1guer Just tried and does not work even with the setting. The extension does not appear in the Extension list.

m1guer commented 1 month ago

can open your logs?

failable commented 1 month ago

Here you go

2024-07-17T23:29:18.09519Z [INFO] compiling Rust extension /Users/user/Downloads/basedpyright-zed
2024-07-17T23:29:18.210935Z [INFO] compiling rust extension /Users/user/Downloads/basedpyright-zed
2024-07-17T23:29:18.389182Z [INFO] checking out python parser
2024-07-17T23:29:18.399757Z [ERROR] failed to compile grammar 'python'

Caused by:
    grammar directory '/Users/user/Downloads/basedpyright-zed/grammars/python' already exists, but is not a git clone of 'https://github.com/tree-sitter/tree-sitter-python'
m1guer commented 1 month ago

try delete the grammar folder in the extension dir and install with pip install badedpyright

failable commented 1 month ago

@m1guer Works like a charm.

m1guer commented 1 month ago

:) has something to do. like do all the schemas for the language.

Greg-Hamel commented 1 month ago

@m1guer Thanks for bringing basedpyright to Zed!

For those curious, the extension is under review at https://github.com/zed-industries/extensions/pull/1080

code-yeongyu commented 1 month ago

Since pyright and basedpyright don't support formatting, I agree with implementing pylsp as default. Here's why pylsp could be a great default:

  1. Extensibility:
  2. Comprehensive tooling via plugins:
    • mypy plugin for type checking
    • ruff plugin for formatting and linting
    • Built-in autocompletion powered by rope

I was thinking that pylsp with mypy and ruff plugins might work well as a default preset. This would facilitate setting up a professional Python development environment.

This preset could allow users to access autocompletion, linting, type checking, and formatting simply by choosing to use pylsp.

Other LSP implementations (pyright, basedpyright, ruff) could be offered as optional extensions for flexibility, giving users more choices if they have specific preferences.

I'd appreciate any thoughts on this approach.

rgbkrk commented 1 month ago

I agree with implementing pylsp as default. ... I'd appreciate any thoughts on this approach.

Give it a shot as an extension - https://github.com/zed-industries/extensions/blob/main/AUTHORING_EXTENSIONS.md. I've been tempted to try it once I finish some other work. Getting an extension out there will help people figure out quickly what's best and how we could incorporate it more deeply.

code-yeongyu commented 1 month ago

I agree with implementing pylsp as default. ... I'd appreciate any thoughts on this approach.

Give it a shot as an extension - zed-industries/extensions@main/AUTHORING_EXTENSIONS.md. I've been tempted to try it once I finish some other work. Getting an extension out there will help people figure out quickly what's best and how we could incorporate it more deeply.

Got it, thanks. As a Python enthusiast who's also into Rust, this could be a good starting point to contribute to Zed.

rgbkrk commented 1 month ago

Sweet, this is probably a good starting point: https://github.com/zed-industries/zed/pull/14198/files

H/T @osiewicz

Greg-Hamel commented 1 month ago

@code-yeongyu Please link your PR to this issue, when you get to it, so we can give it a shot. I'd be very happy to test it for my own use case.

I agree with the opinion that an all-in-one lsp + formatter would be well received.

I currently run black on the side on save at the moment.