Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the Python experience wonderful #7808

Open
3 of 8 tasks
JosephTLyons opened this issue Feb 15, 2024 · 11 comments
Open
3 of 8 tasks

Make the Python experience wonderful #7808

JosephTLyons opened this issue Feb 15, 2024 · 11 comments
Labels
enhancement [core label] language An umbrella label for all programming languages syntax behaviors python Python programming language support

Comments

@JosephTLyons
Copy link
Collaborator

JosephTLyons commented Feb 15, 2024

Check for existing issues

  • Completed

Describe the feature

  • Automatically discover virtual environments and have UI in place for selecting them:
    • Option to select python environments  #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.
    • We could potentially just lean on uv (uv python list) for this.
  • A better language server
  • Notebooks / ipynb support
    • Jupyter Notebook #5273
    • Notebooks are imperative for both data scientists and average python users, for exploration
  • Interactive window
  • 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
    • python Python programming language support

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

@JosephTLyons JosephTLyons added enhancement [core label] python Python programming language support language An umbrella label for all programming languages syntax behaviors labels Feb 15, 2024
@artur-zhdan
Copy link

Jupyter notebook support would be awesome

@failable
Copy link

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

@strangemonad
Copy link

@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
Copy link

basedpyright is your friend.

@mattmess1221
Copy link

basedpyright is your friend.

https:/DetachHead/basedpyright

@frivas
Copy link
Contributor

frivas commented Jun 2, 2024

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
Copy link

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

@JosephTLyons
Copy link
Collaborator Author

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

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

@rgbkrk

@quyvsquy
Copy link

waiting for update

rgbkrk added a commit that referenced this issue Jun 17, 2024
Run any Jupyter kernel in Zed on any buffer (editor):

<img width="1074" alt="image"
src="https:/zed-industries/zed/assets/836375/eac8ed69-d02b-4d46-b379-6186d8f59470">

## TODO

### Lifecycle

* [x] Launch kernels on demand
* [x] Wait for kernel to be started
* [x] Request Kernel info on start
* [x] Show in progress indicator
* [ ] Allow picking kernel (it defaults to first matching language name)
* [ ] Menu for interrupting and shutting down the kernel
* [ ] Drop running kernels once editor is dropped

### Media Outputs

* [x] Render text and tracebacks with ANSI color handling
* [x] Render markdown as text
* [x] Render PNG and JPEG images using an explicit height based on
line-height
* ~~Render SVG~~ -- not happening for this PR due to lack of text in SVG
support
* [ ] Process `update_display_data` message and related `display_id`
* [x] Process `page` data from payloads as outputs
* [ ] Render markdown as, well, rendered markdown -- Note: unsure if we
can get line heights here

### Document

* [x] Select code and run
* [x] Run current line
* [x] Clear previous overlapping runs
* [ ] Support running markdown code blocks
* [ ] Action to export session as notebook or output files
* [ ] Action to clear all outputs
* [ ] Delete outputs when lines are deleted

## Other missing features

The following is a list of missing functionality or expectations that
are out of scope for this PR.

### Python Environments

Detecting python environments should probably be done in a separate PR
in tandem with how they're used with LSP. Users likely want to pick an
environment for their project, whether a virtualenv, conda env, pyenv,
poetry backed virtualenv, or the system. Related issues:

* #7646
* #7808
* #7296

### LSP Integration

* Submit `complete_request` messages for completions to interleave
interactive variables with LSP
* LSP for IPython semantics (`%%timeit`, `!ls`, `get_ipython`, etc.)

## Future release notes

- Run code in any editor, whether it's a script or a markdown document

Release Notes:

- N/A
fallenwood pushed a commit to fallenwood/zed that referenced this issue Jun 18, 2024
Run any Jupyter kernel in Zed on any buffer (editor):

<img width="1074" alt="image"
src="https:/zed-industries/zed/assets/836375/eac8ed69-d02b-4d46-b379-6186d8f59470">

## TODO

### Lifecycle

* [x] Launch kernels on demand
* [x] Wait for kernel to be started
* [x] Request Kernel info on start
* [x] Show in progress indicator
* [ ] Allow picking kernel (it defaults to first matching language name)
* [ ] Menu for interrupting and shutting down the kernel
* [ ] Drop running kernels once editor is dropped

### Media Outputs

* [x] Render text and tracebacks with ANSI color handling
* [x] Render markdown as text
* [x] Render PNG and JPEG images using an explicit height based on
line-height
* ~~Render SVG~~ -- not happening for this PR due to lack of text in SVG
support
* [ ] Process `update_display_data` message and related `display_id`
* [x] Process `page` data from payloads as outputs
* [ ] Render markdown as, well, rendered markdown -- Note: unsure if we
can get line heights here

### Document

* [x] Select code and run
* [x] Run current line
* [x] Clear previous overlapping runs
* [ ] Support running markdown code blocks
* [ ] Action to export session as notebook or output files
* [ ] Action to clear all outputs
* [ ] Delete outputs when lines are deleted

## Other missing features

The following is a list of missing functionality or expectations that
are out of scope for this PR.

### Python Environments

Detecting python environments should probably be done in a separate PR
in tandem with how they're used with LSP. Users likely want to pick an
environment for their project, whether a virtualenv, conda env, pyenv,
poetry backed virtualenv, or the system. Related issues:

* zed-industries#7646
* zed-industries#7808
* zed-industries#7296

### LSP Integration

* Submit `complete_request` messages for completions to interleave
interactive variables with LSP
* LSP for IPython semantics (`%%timeit`, `!ls`, `get_ipython`, etc.)

## Future release notes

- Run code in any editor, whether it's a script or a markdown document

Release Notes:

- N/A
@karimlevallois
Copy link

karimlevallois commented Jun 22, 2024

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

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

@code-yeongyu
Copy link
Contributor

code-yeongyu commented Jul 21, 2024

For those interested in contributing to the implementation of the Ruff extension (linter and formatter): I believe it's now completed (#14198) and available through the extension.

JosephTLyons pushed a commit that referenced this issue Sep 29, 2024
The `uv` python package manager uses the TOML for it's `uv.lock` file,
see https://docs.astral.sh/uv/guides/projects/#uvlock.

Ref #7808

Release Notes:

- associate `uv.lock` files with the TOML language
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement [core label] language An umbrella label for all programming languages syntax behaviors python Python programming language support
Projects
None yet
Development

No branches or pull requests

9 participants