Make the Python experience wonderful #7808
Comments
JosephTLyons
added
feature
|
Jupyter notebook support would be awesome |
|
For LSP, there is also https://github.com/pappasam/jedi-language-server . |
|
@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
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. |
|
basedpyright is your friend. |
|
|
When detecting environments I would also suggest to include I know this is Rust however some ideas might be useful from VSCode and checking the |
|
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! |
|
waiting for update |
Run any Jupyter kernel in Zed on any buffer (editor): <img width="1074" alt="image" src="https://github.com/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
Run any Jupyter kernel in Zed on any buffer (editor): <img width="1074" alt="image" src="https://github.com/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
|
basedpyright now includes standard library docstrings, can we please just have this over pyright? https://github.com/DetachHead/basedpyright/releases/tag/v1.13.0 |
|
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. |
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
The `uv` python package manager uses the TOML for it's `uv.lock` file, see https://docs.astral.sh/uv/guides/projects/#uvlock. Ref zed-industries#7808 Release Notes: - associate `uv.lock` files with the TOML language
|
Big +1 for uv integration in Zed! I have been using both recently and think they'd mesh very well together. For example, being able to run I abused the Zed extensions API to make this, an extension that calls uv from the AI assistant panel using slash commands. It's not really meant for serious use, but more of an experiment of what it could feel like to interface with uv from within Zed. From a Python perspective, I imagine there will be folks who just want to use pip, or maybe poetry, or conda...with such a rich ecosystem of package management and build tooling I think a one-size-fits-all solution may not be feasible. I suggest that Zed focus on exposing an API surface that enables different extensions for these workflows. Even just being able to add a command to the command palette would enable a lot of cool possibilities. This would allow other language communities to build similar workflows using the same tools. |
Fixes part of issue #7808 > This venv should be the one we automatically activate when opening new terminals, if the detect_venv setting is on. Release Notes: - Selected Python toolchains (virtual environments) are now automatically activated in new terminals. --------- Co-authored-by: Piotr Osiewicz <[email protected]>
Check for existing issues
Describe the feature
venv,.venv,virtual_envinronment) and venvs installed in the global space.detect_venvsetting is on.pyrightconfig.jsonfile, 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.uv python list) for this.astral.sh?pylsppylyzerruffruffWe 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
The text was updated successfully, but these errors were encountered: