Manim 0.21.0: two engines named manim, a refactor in progress, and no feature PRs

Two engines answer to the name manim, and the README warns you twice

This repository is the community edition, ManimCE, forked from 3b1b/manim, which Grant Sanderson created and open-sourced, and which he still maintains separately. The project recommends its own version for continued development, improved features, enhanced documentation, and more active community-driven maintenance, and points anyone who wants to study how Grant makes his videos at the other repository.

The installation section then repeats the warning in a caution block: these instructions are for the community version only, and using them for 3b1b/manim, or using that project's instructions here, will cause problems. The block links a FAQ page explaining why there are different versions of manim and tells you to decide which one you want before following any instructions.

Consequence for you: almost every tutorial, blog post, and error message on the web that mentions manim is ambiguous between the two engines, so pick one deliberately and read only that project's documentation. Copying a config file or a dependency list from the other fork is the failure mode the caution names, and it fails at runtime rather than at install time.

Feature pull requests are being declined while the refactor runs

The contributing section is unusually direct. It says contributions are welcome, names a dire need for tests and documentation, and then states that Manim is currently undergoing a major refactor and that, in general, contributions implementing new features will not be accepted in this period. It also warns that the contribution guide may become outdated quickly and recommends joining the Discord server to discuss any proposed work and to keep up with developments. Developers on the project use uv for environment management.

Consequence for you: a pull request that adds a mobject or a new animation class is the kind of contribution the project says it will decline, so plan your upstream work around tests and documentation, where the stated need is real. It also means the API you read on the main branch may differ from the API in 0.21.0, and that the contributing guide itself can be stale, which pushes the real conversation into a chat server rather than an issue tracker.

manim and manimce are two names for the same function

The project metadata defines two console scripts, and both point at one target:

[project.scripts]
"manim" = "manim.__main__:main"
"manimce" = "manim.__main__:main"

Consequence for you: an environment that already has a manim command on the PATH may be answering with the other engine, and there is no version check in the front page to tell you which one just ran. The community-specific alias exists so a script can name the community edition explicitly, which is the only reliable way to disambiguate when both engines are in play on the same machine. The README example uses the plain name, so copy the alias into your own scripts if you ever have both installed.

Python 3.11 is the floor, and the dependency set shifts at 3.13

The project declares requires-python as 3.11 or newer and ships classifiers for 3.11, 3.12, 3.13, and 3.14, so 3.10 and older cannot install this release. The dependency list runs to 27 lines, and it is not a flat list: audioop-lts appears only for interpreters at 3.13 and above, and scipy is listed twice, once at 1.13.0 and again at 1.15.0 for 3.13 and above.

Those markers are the interesting part. audioop was removed from the standard library, so the audio path is supplied by a backport package on the newer interpreters, and the scipy floor moves with it. Consequence for you: pinning an older interpreter changes which packages get installed, so a lockfile built on 3.12 is not the same set of wheels as one built on 3.13. The project also classifies itself as Development Status 4 - Beta, which is its own statement about how much the API can still move.

The install is a native and OpenGL stack, not a pure Python package

Look at what has to be present before anything renders: pycairo for 2D drawing, manimpango for text shaping, skia-pathops for path operations, isosurfaces and mapbox-earcut for three-dimensional shapes, moderngl together with moderngl-window for OpenGL rendering, av for video encoding, pydub for audio, srt for subtitles, watchdog for file watching, and screeninfo for display information.

Consequence for you: this is not a pip-only install. C library headers and an OpenGL-capable display have to exist first, which is why the README sends you to per-operating-system instructions rather than printing one command, and why it points at a Docker image, manimcommunity/manim, as the alternative route. A headless Linux box with no GPU and no X display is where this dependency set bites, and the failure shows up as a rendering error long after the install succeeded.

Five command line flags are documented, the rest live in a guide

The usage example is one scene class and one command:

manim -p -ql example.py SquareToCircle

Here -p means preview, so the finished file opens in your native video player, and -ql asks for faster rendering at lower quality. Three more flags get a line each: -s to skip to the end and show only the final frame, -n to skip ahead to a numbered animation within a scene, and -f to show the output in the file browser. A full list is one link away in the configuration guide.

Consequence for you: quality is a command line flag rather than a configured default, so a low quality render is one flag and a high quality final render is another, and the difference is not described on the front page. The scene class is the real interface, and the example is deliberately tiny: a construct method that creates a square and a circle, flips and rotates one, and plays Create, Transform, and FadeOut. Reading a dozen example_scenes files is the fastest way past the five flags.

The notebook path is a magic, the online path is someone else's kernel

Two escape hatches let you avoid a local install. There is an online Jupyter environment at try.manim.community, described as a way to try it before installing locally, and Manim ships a %%manim IPython magic that works in JupyterLab and in classic Jupyter notebooks, with a Binder notebook linked for trying it online. The front page also points at the example_scenes directory in the repository and at the official gallery for more advanced examples.

Consequence for you: the online environment tells you whether the idea works, not whether your machine can run it, since the native stack is exactly what the hosted kernel already has. The %%manim magic is the part that survives into local work, and it lets you iterate in a notebook instead of saving a file per scene. Editor-specific setups are not covered here at all; the README defers to the documentation site for anything beyond the flags it names.

Two license files, a Beta classifier, and docs translated through Crowdin

The metadata names the MIT license and points at two license files, LICENSE and LICENSE.community, which is the fork's history showing through. Citation is handled by a button: the project asks you to cite Manim, and the recommended route is the cite this repository button on the repository page, which produces a citation in your preferred format and works with citation managers. The tree also carries CITATION.cff, a crowdin.yml for translated documentation, a benchmarks/ directory, a logo/ directory, and a scripts/ directory.

Consequence for you: a compliance check should read both license files rather than the single MIT string, and a translated manual can lag the English one because the translation runs through an external service. The citation request matters more than it looks: the project treats academic credit as part of the deal, and the button is the mechanism it asks you to use rather than a version number you have to look up.

Editorial conclusion

Manim fits a Python author who wants frame-precise control of an explanatory animation and can accept a Python 3.11 floor, a native dependency stack, and an API that is moving during a refactor; the example scene is small enough to prove the toolchain in an afternoon. It does not fit someone looking for a stable API to build a large library on, a zero-dependency pip install, or instructions that cover a specific editor, since the front page defers all of that to the documentation site. Before you commit, read the fork note and pick one of the two engines, check that your platform has the cairo, pango, and OpenGL pieces the install needs, and treat 0.21.0 as Beta, which is how the project classifies itself.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes