Make the Python experience wonderful

JosephTLyons commented 4 months ago

Check for existing issues

[X] Completed

Describe the feature

[ ] Automatically discover virtual environments and have UI in place for selecting them:
- https://github.com/zed-industries/zed/issues/7646
- We should detect both venvs that exist in the project itself, looking for conventional folder names (venv, .venv, virtual_envinronment) and venvs installed in the global space.
- A button in the status bar that opens up a modal. Should the button only be available when in python files?
- This venv should be the one we automatically activate when opening new terminals, if the detect_venv setting is on. It could also be used to automatically generate a pyrightconfig.json file, in the short term, while we still use pyright. It can be used in the future code runner, as well. What should we do with the current logic that tries to automatically detect venvs? Maybe it just gets deprecated.
[ ] A better language server
- https://github.com/zed-industries/zed/issues/7296
- Not much we can do now, but maybe one of these will pan out
  - astral.sh?
  - pylsp
  - pylyzer
[ ] Notebooks / ipynb support
- https://github.com/zed-industries/zed/issues/5273
- Notebooks are imperative for both data scientists and average python users, for exploration
[ ] Interactive window
- https://github.com/zed-industries/zed/issues/6787
[ ] Linter - ruff
- Baked in and shipped with Zed, as the default, with options to customize to something else, if wanted
- Could also just be an extension
[ ] Formatter - ruff
- Baked in and shipped with Zed, as the default, with options to customize to something else, if wanted
- Could also just be an extension
[ ] Backlog of issues
- https://github.com/zed-industries/zed/labels/python

We will also need these things, but these things are generic and aren't specific to Python

It seems like some of these should ship directly with Zed, but maybe some of them should come in the form of extensions. We should have a conversation with the team about this.

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

No response

artur-zhdan commented 4 months ago

Jupyter notebook support would be awesome

failable commented 4 months ago

For LSP, there is also https://github.com/pappasam/jedi-language-server .

strangemonad commented 3 months ago

@JosephTLyons I'm super excited about the prospect of a more streamlined python experience. I agree that the key points you've pointed out are probably the correct pain points but have a few thoughts. I'll drop more detailed notes in the relevant issues but a high-level summary of my thoughts.

Detecting Venv I would expand this to 2 things 1) robustly detecting the project root (e.g. abs path to pyproject.toml or requirements.txt+setup.py or ..., or allow user to specify a project root as a final fallback) 2) detecting the venv Combined, I think these 2 things are the keystone that make everything else just fall into place smoothly. I think it may be worthwhile looking at what uv (from astral) has already done to robustly detect python paths and try and piggy back on that.

LSP I think the pyright experience can be made better. I'm all for allowing folks to choose a different LSP but having supported project configs in multiple large python code bases, I think correctly invoking pyright will be the best option to get good results in the short to medium term compared to any other option. The main reason I think this is that despite the clunky pyright lsp invocation, as soon as it's pointed to the right environement, the type checker has been the most complete, robust, and fast in my experience and it would take a while for other tools to catch up. Details in #7296

Lint and format +1 for ruff as far as I'm concerned.

karimlevallois commented 3 months ago

basedpyright is your friend.

killjoy1221 commented 1 month ago

basedpyright is your friend.

https://github.com/DetachHead/basedpyright

frivas commented 1 month ago

When detecting environments I would also suggest to include conda. To verify this check the CONDA_PREFIX environment variable which by adding bin will point to, for example, a Python interpreter.

I know this is Rust however some ideas might be useful from VSCode and checking the native_locator folder there are other locators.

strangemonad commented 1 month ago

a tangential set of issues that may be worth tracking in the astral uv project

https://github.com/astral-sh/uv/issues/2386 covers the logic used to find the correct python interpreter
https://github.com/astral-sh/uv/issues/2813 is a future feature request to allow calling out to uv to return the discovered interpreter.

JosephTLyons commented 1 month ago

a tangential set of issues that may be worth tracking in the astral uv project

Selecting a Python interpreter astral-sh/uv#2386 covers the logic used to find the correct python interpreter

Feature Request: Expose python and venv discovery as a machine interpretable uv subcommand astral-sh/uv#2813 is a future feature request to allow calling out to uv to return the discovered interpreter.

This is awesome! That second issue about discovery would be really useful!

@rgbkrk

quyvsquy commented 2 weeks ago

waiting for update

karimlevallois commented 2 weeks ago

basedpyright now includes standard library docstrings, can we please just have this over pyright?

https://github.com/DetachHead/basedpyright/releases/tag/v1.13.0

zed-industries / zed