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
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
make html
```
### Clean
# 3) Preview documentation locally
To remove all generated files:
# Open your browser at the displayed port to view the docs
```
bash serve.sh
make clean
```
### Serve (preview)
# 4) Clean notebook outputs
Run an HTTP server and visit http://localhost:8000 in your browser.
# 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
...
@@ -6,31 +6,15 @@ Welcome to **SGLang**! We appreciate your interest in contributing. This guide p
### Fork and Clone the Repository
### 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.
Refer to [Install SGLang](https://sgl-project.github.io/start/install.html) documentation for more details on setting up the necessary dependencies.
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.
Install correct version of flashinfer according to your PyTorch and CUDA versions.
# Install the lateset SGLang on your own fork repo
cd sglang/python
pip install .
```
## Code Formatting with Pre-Commit
## Code Formatting with Pre-Commit
...
@@ -38,130 +22,19 @@ We use [pre-commit](https://pre-commit.com/) to maintain consistent code style c
...
@@ -38,130 +22,19 @@ We use [pre-commit](https://pre-commit.com/) to maintain consistent code style c
```bash
```bash
pip3 install pre-commit
pip3 install pre-commit
cd sglang
pre-commit run --all-files
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.
-**`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.
-**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.
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
- Examine existing tests in [sglang/test](https://github.com/sgl-project/sglang/tree/main/test) for practical examples.
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).
- 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.
- 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>