c1fd648390
This isn't ready to go - I'm opening a PR to ask for some advice. When activating a python virtual environment, the typical command used is `source path_to_venv/bin/activate`. The problem is, the activatate script isn't portable to all shells, so some additional scripts are bundled in the env, for example, `activate.fish`. We don't have a good way of knowing what shell we are in, in order to know what script to run. Julia gave the alternative of simply activating the virtual environment while in the zsh context, before the user's custom shell is launched, which I think does work, but because we activate the virtual environment before we launch the custom shell, the shell isn't really aware that we are in the virtual environment and it fails to display the information in the prompt that is typically shown after activating. Is there a clean way for us to know for a fact what shell is being ran, so we know what script to run? Check out the code comments below for more context. --- https://github.com/zed-industries/zed/assets/19867440/ddb76aaa-152b-4c93-a513-3cd580b7c40f I've used Zed to write Python scripts, but working on an actual project has really magnified where Python dev is falling short. A huge quality-of-life thing we can do is provide a setting to automaticaly search for and activate virtual environments when found, when terminals are created. Manually starting these up in every terminal instance is such a drag. A few quirks: - We don't have a way of knowing if the prompt is ready before we try run the command, which means we see the text inserted at the top of the terminal and on the prompt - I dont think this should be a blocker though. - If a user has multiple python projects with mutliple virtual environments, we only detect and activate the first one, since can't really make any assumptions about which one to activate. I dont think this should be a blocker either, as I think most users will have a single project open in Zed. Release Notes: - Added a `detect_venv` setting for the terminal. When configured, the Zed terminal will automatically activate Python virtual environments on terminal creation. |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .vscode | ||
| .zed | ||
| assets | ||
| crates | ||
| docs | ||
| plugins | ||
| script | ||
| styles | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Dockerfile | ||
| Procfile | ||
| README.md | ||
| rust-toolchain.toml | ||
| test.rs | ||
Zed
Welcome to Zed, a lightning-fast, collaborative code editor that makes your dreams come true.
Development tips
Dependencies
-
Install Postgres.app and start it.
-
Install the
LiveKitserver and theforemanprocess supervisor:brew install livekit brew install foreman -
Ensure the Zed.dev website is checked out in a sibling directory and install it's dependencies:
cd .. git clone https://github.com/zed-industries/zed.dev cd zed.dev && npm install npm install -g vercel -
Return to Zed project directory and Initialize submodules
cd zed git submodule update --init --recursive -
Set up a local
zeddatabase and seed it with some initial users:Create a personal GitHub token to run
script/bootstraponce successfully: the token needs to have an access to private repositories for the script to work (repoOAuth scope). Then delete that token.GITHUB_TOKEN=<$token> script/bootstrap
Testing against locally-running servers
Start the web and collab servers:
foreman start
If you want to run Zed pointed at the local servers, you can run:
script/zed-with-local-servers
# or...
script/zed-with-local-servers --release
Dump element JSON
If you trigger cmd-alt-i, Zed will copy a JSON representation of the current window contents to the clipboard. You can paste this in a tool like DJSON to navigate the state of on-screen elements in a structured way.
Licensing
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Wasm Plugins
Zed has a Wasm-based plugin runtime which it currently uses to embed plugins. To compile Zed, you'll need to have the wasm32-wasi toolchain installed on your system. To install this toolchain, run:
rustup target add wasm32-wasi
Plugins can be found in the plugins folder in the root. For more information about how plugins work, check the Plugin Guide in crates/plugin_runtime/README.md.