Max Brunsfeld
647b08b101
When testing Zed locally, it's rarely necessary to log in the real with, via Zed.dev and GitHub. We usually use `zed-local`. Since zed.dev is not going to be open source (at least right away), this PR removes it from our local development workflow. * Remove zed.dev from the Procfile * Change the `seed` script to not create an admin user for your signed-in github user * Instead have both `zed-local` and the `seed` script read from an `.admins.json` file, which the user can create in order to customize who they sign in as when running `zed-local`. * Update all of the docs for building and developing zed.
🚧 TODO 🚧
- Add intro
- Add link to contributing guide
- Add barebones running zed from source instructions
- Link out to further dev docs
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Developing Zed
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
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.