OI Wiki's local build fetches a theme over the network and renders MathJax on the server

Local setup fetches the theme over the network before mkdocs will serve

The documented order is not the one most people guess. Cloning the repository is the easy part; the theme is the part that reaches out to the network.

git clone https://github.com/OI-wiki/OI-wiki.git --depth=1
cd OI-wiki
pip install uv
uv sync --index-url https://pypi.tuna.tsinghua.edu.cn/simple/
./scripts/pre-build/install-theme.sh
uv run mkdocs serve -v

That script is where a corporate proxy, an offline machine or a restricted network bites. The theme lives in a mkdocs-material directory tracked as a submodule, and the install script downloads vendor resources whose addresses are controlled by the url entry in .gitmodules and by MATHJAX_URL and MATERIAL_ICONS_URL in scripts/pre-build/install-theme-vendor.sh. On Windows the README says to run it under Git Bash.

uv run mkdocs serve -v then serves the site at http://127.0.0.1:8000, and uv run mkdocs build -v writes static pages into the site folder if you would rather have files.

MathJax renders on the server, so a local preview shows formulas raw

The live site renders MathJax server-side, and the README says plainly that reproducing that locally means following the build workflow in .github/workflows/build.yml, which needs Node.js installed.

That is an unusual split. The Python environment builds the Markdown and the layout, while the equation rendering happens in the Node half of the pipeline. The TypeScript side of the repository is not incidental: package.json pulls @mathjax/src and @swc/core, and the pyproject.toml environment pins mkdocs==1.5.3 and pymdown-extensions==11.0.1 alongside markdown==3.9 and a document-offsets extension, so the two halves are versioned separately and have to agree.

The consequence for a contributor is specific: uv run mkdocs serve -v gives you a working site with unrendered formulas, and the recipe for fixing that is a CI workflow file rather than a paragraph of documentation. Read the workflow before you conclude your local checkout is broken.

The Dockerfile takes WIKI_REPO and PYPI_MIRROR, and listens on 0.0.0.0

The container is the answer for networks that cannot reach GitHub or PyPI. It starts from ubuntu:22.04, installs build tools, Node 18 through the nodesource setup script, and uv from the astral.sh installer, then clones with git clone ${WIKI_REPO:-https://github.com/OI-wiki/OI-wiki.git} --depth=1 and runs uv sync and yarn --frozen-lockfile.

The comment above that clone is the useful part: if you cannot connect to GitHub, set WIKI_REPO to any mirror repo, and PYPI_MIRROR does the same for the package index. The README names a Gitee mirror whose content is identical to GitHub, so a build behind a filter can be assembled from the two.

One default deserves attention. LISTEN_IP is set to 0.0.0.0 while the port defaults to 8000, so the container binds every interface, whereas the documented local URL is http://127.0.0.1:8000. Publishing that container means fronting it with a reverse proxy you supply.

gh-pages is the offline edition, and it needs an HTTP server

There is no GitHub release to download and no PDF to grab. The offline edition is a branch.

git clone https://gitee.com/OI-wiki/OI-wiki.git -b gh-pages
python3 -m http.server

The README suggests running a local HTTP server as the more convenient option, and gives the python3 and python2 forms, noting that some environments do not have an executable named python3 or python2 and that you can try python. That advice is the tell: the built pages expect to be fetched over HTTP rather than opened from disk, so double-clicking an index file in a file browser is not a supported path.

What you get from the branch is a snapshot with no version number attached, and the repository publishes no releases to compare it against. For a permanent offline copy, keep your own clone of the branch and a note of when you took it.

remark rejects duplicate headings inside a section, which bites algorithm pages

The content is linted as carefully as the code. package.json formats docs with remark docs/ -o and checks them by running a TypeScript checker through ts-node, and the dependency list is mostly remark plugins.

Two of those plugins constrain what a page can say. remark-lint-no-duplicate-headings-in-section fails a page that uses the same heading twice inside one section, which is exactly the shape a competitive programming article takes when it walks through several variants of the same data structure. remark-lint-no-tabs and remark-lint-final-newline handle the rest of the formatting, remark-math and remark-math-space cover the formulas, remark-clang-format formats the embedded C++, and remark-copywriting-correct checks the Chinese prose. .clang-format at the repository root carries the C++ style for the same reason.

So a page that reads fine in an editor can still fail the check, and the failure is about structure rather than content.

The project names its own gaps and where they are tracked

The README is unusually direct about quality. It says the content still has a lot to improve, that knowledge coverage leaves obvious gaps, and that some pages are low quality and need revision, and it names the two places to look: the issue tracker and an iteration plan label.

That is worth taking at face value when you plan study time. Nothing in the repository suggests a page exists for a topic just because the site loads, and a competition preparation plan that assumes coverage will produce a gap you discover the week of the contest.

The governance side is stated as plainly as the quality side. The project describes itself as rooted in the community, says it will never be commercialised, and says it will always remain independent. It moved to GitHub in July 2018, has no GitHub releases, and the last push to the master branch was on 2026-09-28.

CC BY-SA 4.0 with a star request, no LICENSE file, and UNLICENSED in package.json

The copyright section says that, except where otherwise noted, everything apart from the code is under Creative Commons BY-SA 4.0 together with The Star And Thank Author License. In the project's own summary of what that means: you may share and adapt freely, but you must attribute, share alike, and add no further restrictions, and you should star the GitHub repository.

The repository layout does not make that obvious. The root holds CITATION.bib with a BibTeX entry and no LICENSE file, and package.json declares the license as UNLICENSED, which is the npm convention for code that is not being published as a package. A reader looking for a licence file will not find one and has to read the README to learn the terms, including the request that reuse be acknowledged with a star.

If you are building on the content rather than reading it, those obligations travel with whatever you copy, and the code is the only part the README excludes from them.

The alternative is your own MkDocs site, and the model is CTF Wiki

The project names its own inspiration: the acknowledgements say it was inspired by CTF Wiki, and both are community-run, free, non-commercial wikis of the same kind rather than products with a company behind them.

The other approach is to run MkDocs on your own notes. It is the same mkdocs==1.5.3 engine and the same Markdown, but you skip the mkdocs-material submodule, the install-theme.sh download, the Node.js step for server-side MathJax and the remark rule set. You get a site that renders on your machine with no network, and you get none of the corpus, none of the review and none of the mirror list at status.oi-wiki.org that the project maintains for readers who cannot reach the main domain.

Choose between them on the question you are answering. Algorithm reference material you need once is faster to get from your own folder; a maintained Chinese-language corpus with an iteration plan, mirror coverage and community review only exists as this repository.

Editorial conclusion

Adopt the repository if you want to read and improve the corpus, or to mirror it where oi-wiki.org is unreachable, and read the issues plus the Iteration Plan label before assuming a topic is covered. Do not adopt it as a ready-made offline reference without checking the gh-pages branch, and do not copy pages into a commercial product until you have read the licensing section, because the project's own terms attach attribution, share-alike and a star request to reuse. Verify first that your machine can reach the two download hosts the setup script needs, and that uv run mkdocs serve -v gives you the equations or only the raw markup.

Frequently asked questions

Official sources

1. Issues
2. OI-wiki/OI-wiki on GitHub
3. Project website
4. README