This is the documentation repository for SGLang. It is auto-generated from https://github.com/sgl-project/sglang/tree/main/docs.
We recommend new contributors start from writing documentation, which helps you quickly understand SGLang codebase. Most documentation files are located under the `docs/` folder. We prefer **Jupyter Notebooks** over Markdown so that all examples can be executed and validated by our docs CI pipeline.
## Build the documentation website
## Docs Workflow
### Dependency
```
### Install Dependency
```bash
pip install-r requirements.txt
```
### Build
```
### Update Documentation
Update your Jupyter notebooks in the appropriate subdirectories under `docs/`. If you add new files, remember to update `index.rst` (or relevant `.rst` files) accordingly.
-**`pre-commit run --all-files`** manually runs all configured checks, applying fixes if possible. If it fails the first time, re-run it to ensure lint errors are fully resolved. Make sure your code passes all checks **before** creating a Pull Request.
-**Do not commit** directly to the `main` branch. Always create a new branch (e.g., `feature/my-new-feature`), push your changes, and open a PR from that branch.
```bash
# 1) Compile all Jupyter notebooks
make compile
# 2) Generate static HTML
make html
```
### Clean
To remove all generated files:
```
make clean
```
# 3) Preview documentation locally
# Open your browser at the displayed port to view the docs
bash serve.sh
### Serve (preview)
Run an HTTP server and visit http://localhost:8000 in your browser.
# 4) Clean notebook outputs
# nbstripout removes notebook outputs so your PR stays clean
pip install nbstripout
find .-name'*.ipynb'-exec nbstripout {}\;
# 5) Pre-commit checks and create a PR
# After these checks pass, push your changes and open a PR on your branch
pre-commit run --all-files
```
python3 -m http.server --d _build/html
If you need to run and shut down a SGLang server or engine, following these examples:
@@ -6,31 +6,15 @@ Welcome to **SGLang**! We appreciate your interest in contributing. This guide p
### Fork and Clone the Repository
**Note**: SGLang does**not**accept PRs on the main repo. Please fork the repository under your GitHub account, then clone your fork locally.
**Note**: New contributors do **not**have the write permission to push to SGLang. Please fork the repository under your GitHub account, then clone your fork locally.
# Install the lateset SGLang on your own fork repo
cd sglang/python
pip install .
```
Refer to [Install SGLang from Source](https://sgl-project.github.io/start/install.html#method-2-from-source) documentation for more details on setting up the necessary dependencies.
## Code Formatting with Pre-Commit
...
...
@@ -38,130 +22,19 @@ We use [pre-commit](https://pre-commit.com/) to maintain consistent code style c
```bash
pip3 install pre-commit
cd sglang
pre-commit run --all-files
```
-**`pre-commit run --all-files`** manually runs all configured checks, applying fixes if possible. If it fails the first time, re-run it to ensure lint errors are fully resolved. Make sure your code passes all checks **before** creating a Pull Request.
-**Do not commit** directly to the `main` branch. Always create a new branch (e.g., `feature/my-new-feature`), push your changes, and open a PR from that branch.
## Writing Documentation & Running Docs CI
Most documentation files are located under the `docs/` folder. We prefer **Jupyter Notebooks** over Markdown so that all examples can be executed and validated by our docs CI pipeline.
### Docs Workflow
Add or update your Jupyter notebooks in the appropriate subdirectories under `docs/`. If you add new files, remember to update `index.rst` (or relevant `.rst` files) accordingly.
```bash
# 1) Compile all Jupyter notebooks
make compile
# 2) Generate static HTML
make html
# 3) Preview documentation locally
bash serve.sh
# Open your browser at the displayed port to view the docs
# 4) Clean notebook outputs
pip install nbstripout
find .-name'*.ipynb'-exec nbstripout {}\;
# nbstripout removes notebook outputs so your PR stays clean
# 5) Pre-commit checks and create a PR
pre-commit run --all-files
# After these checks pass, push your changes and open a PR on your branch
```
If you need to run and shut up a SGLang server or engine, following these examples:
SGLang uses Python’s built-in [unittest](https://docs.python.org/3/library/unittest.html) framework. You can run tests either individually or in suites.
### Test Backend Runtime
```bash
cd sglang/test/srt
# Run a single file
python3 test_srt_endpoint.py
SGLang uses Python's built-in [unittest](https://docs.python.org/3/library/unittest.html) framework. For detailed instructions on running tests and adding them to CI, please refer to [test/README.md](https://github.com/sgl-project/sglang/tree/main/test/README.md).
- Create new test files under `test/srt` or `test/lang` depending on the type of test.
- Ensure they are referenced in the respective `run_suite.py` (e.g., `test/srt/run_suite.py` or `test/lang/run_suite.py`) so they’re picked up in CI.
- In CI, all tests run automatically. You may modify the workflows in [`.github/workflows/`](https://github.com/sgl-project/sglang/tree/main/.github/workflows) to add custom test groups or extra checks.
### Writing Elegant Test Cases
## Writing Documentation & Running Docs CI
- Examine existing tests in [sglang/test](https://github.com/sgl-project/sglang/tree/main/test) for practical examples.
- Keep each test function focused on a single scenario or piece of functionality.
- Give tests descriptive names reflecting their purpose.
- Use robust assertions (e.g., assert, unittest methods) to validate outcomes.
- Clean up resources to avoid side effects and preserve test independence.
We recommend new contributors start from writing documentation, which helps you quickly understand SGLang codebase. For more details, please refer to [docs/README.md](https://github.com/sgl-project/sglang/tree/main/docs/README.md).
- Create new test files under `test/srt` or `test/lang` depending on the type of test.
- Ensure they are referenced in the respective `run_suite.py` (e.g., `test/srt/run_suite.py` or `test/lang/run_suite.py`) so they’re picked up in CI.
- In CI, all tests run automatically. You may modify the workflows in [`.github/workflows/`](https://github.com/sgl-project/sglang/tree/main/.github/workflows) to add custom test groups or extra checks.
## Writing Elegant Test Cases
- Examine existing tests in [sglang/test](https://github.com/sgl-project/sglang/tree/main/test) for practical examples.
- Keep each test function focused on a single scenario or piece of functionality.
- Give tests descriptive names reflecting their purpose.
- Use robust assertions (e.g., assert, unittest methods) to validate outcomes.
- Clean up resources to avoid side effects and preserve test independence.
Chayenne <zhaochen20@outlook.com>