Nikola's newest tag is 8.3.3 from May 2025 while master kept moving

The release trail stops at 8.3.3 while master carries pushes past it

Three releases are published. v8.3.1 on 2024-04-29, then a gap of more than a year, then v8.3.2 and v8.3.3 on the same afternoon, 2025-05-17 at 17:29 and 18:13 UTC, forty four minutes apart. The project metadata on master still reads version = "8.3.3", so the number in the metadata is the newest tag rather than something that moves with each commit. The last push to the default branch is dated 2026-09-20, roughly sixteen months after that tag. In other words, anyone installing from the package index gets 8.3.3, and anyone tracking master gets whatever has landed since, including whatever CHANGES.txt at the top level records and whatever has not been tagged yet.

The install hook deletes the installed package tree before writing a new one

setup.py overrides two setuptools commands, install and build_py, and both call a function named expands_symlinks_for_windows() before doing their real work. That function returns immediately unless sys.platform is win32. On Windows it imports a winutils module and calls fix_all_git_symlinked on the checkout, because a symlink there is stored as a text file holding a path, and installing straight from a git clone otherwise produces files with bad content. The trade is stated in the function's own docstring: after install the working copy is dirty, since the symlink markers have been overwritten with real content. When any file cannot be repaired the script prints that your working copy is now dirty by changes in samplesite, sphinx and themes, then raises, with the instruction that your best bet is to start again from clean. The same run also calls remove_old_files(), which rmtree's the whole installed nikola directory, ignoring errors.

Three pip lines, two extras keys, and no key at all

The installation section is short enough to quote whole:

pip install Nikola
pip install "Nikola[extras]"
pip install "Nikola[extras,tests]"

The extras keys are the interesting part, because nothing in the README says what either one contains. Optional features are mentioned, tests are mentioned, and two keys are offered, but the mapping from key to feature is left to the project website. Note the capital N in every command: the distribution is `Nikola` while the repository, the importable package directory and the pip command people type from memory are all lowercase. That is a small thing to trip on, since pip normalises names, but it is the shape of the project's own metadata. A fourth packaging route exists in the tree without appearing here at all: snapcraft.yaml sits at the top level, and the installation section never mentions Snap.

Two markup parsers are unconditional, and the dependency list ends mid-list

The project metadata names fourteen dependencies and then stops at `piexif>=1.0.3`, with no closing bracket after it. What is visible is enough to explain the README's claims. `docutils>=0.19` and `Markdown>=3.0` are both unconditional, which is what backs the promise that reStructuredText or Markdown both work as input languages, alongside Wiki, BBCode, Textile and HTML. `mako>=1.0.9` and `Pygments>=2.4.2` cover templating and the syntax highlighting the README advertises for almost any language or markup. `Pillow>=9.1.0` and `piexif>=1.0.3` point at the image galleries you get by dropping files into a folder. `PyRSS2Gen>=1.1` sits next to the blog bullet that promises feeds and archives, `lxml>=4.5.2` handles the XML side, and `requests>=2.31.0` arrives while the themes and plugins are documented as living on their own sites, themes.getnikola.com and plugins.getnikola.com.

Fifty languages arrive through Transifex and are tracked in two directories

The README's feature list claims multilingual sites translated to 50 languages, and the claim points at a Transifex project page. The top level backs that up with two separate entries: `.tx/`, which is where the Transifex client keeps its configuration, and `translations/`, which is the other half. Two mechanisms for the same job in one repository is a detail worth noticing if you plan to send a pull request with translated strings, because you have to know which of the two directories the tooling reads. The rest of the top level follows the same pattern of infrastructure kept next to the code: `docs/` with a `.readthedocs.yaml` for hosted documentation, `tests/` with a `.coveragerc`, `AUTHORS.txt` and `CHANGES.txt`, a CODE_OF_CONDUCT.md, a SECURITY.md, a CONTRIBUTING.rst, and `logo/` for the artwork.

The architecture is one image hosted on the project website

The README has a section headed Nikola Architecture and it contains exactly one thing: an image directive pointing at https://getnikola.com/images/architecture.png. There is no prose under it and no component list in the repository text. So the picture of how the pieces fit together is fetched from the project website rather than versioned with the code, and a reader who clones the repository and never opens a browser gets the feature bullet list instead of the design. The section above it, Why Static Websites, is three claims in one sentence, that static sites are safer, use fewer resources, and avoid vendor and platform lock-in, and it delegates the argument to a handbook anchor. The README's stated goal is the same idea in six words: in goes content, out comes a website, ready to deploy.

dodo.py carries the build and the claims about speed point at it

The README says fast builds come from `doit`, and the metadata pins `doit>=0.33.1` as an unconditional dependency. The task file itself is `dodo.py` at the top level, so the build runner's entry point sits in the open next to setup.py rather than inside a build directory. `setup.cfg` sits there too, so this project runs the older split between pyproject.toml, setup.cfg and a setup.py that still carries custom commands, even though the build backend is plain setuptools.build_meta with setuptools>=60.0.5 and wheel. One more directory deserves a question before you rely on it: `npm_assets/` is at the top level, which means theme assets are not only Python, yet the README says nothing about how they are built and no JavaScript build step is mentioned in the installation section that quotes three pip lines.

Editorial conclusion

Nikola fits a site that wants comments, feeds, image galleries and syntax highlighting from a Python tool with no server to run. Read setup.py before installing on Windows, because the install hook rewrites the working copy and raises rather than continuing when it cannot repair every symlink. Check your Python version against the 3.10 floor and the 3.14 ceiling in the classifiers, and decide whether a package whose newest tag is 8.3.3 from 2025-05-17 suits a site you still have to maintain.

Frequently asked questions

Official sources

1. getnikola/nikola on GitHub
2. License: MIT
3. Project website
4. README
5. Releases