RustPython: what cargo install gives you when the repository has no stable release

There is no release tag, so cargo install tracks a moving branch

The repository's only GitHub release is a pre-release from 2025-03-05, which changes what an install actually means. The documented path is:

$ cargo install --git https://github.com/RustPython/RustPython rustpython
$ rustpython
Welcome to the magnificent Rust Python interpreter
>>>>>

That command names no revision, so it takes the tip of the default branch at the moment you run it. Two people installing a week apart can get different interpreters, and nothing in the command records which one. The manifest sets its version from the workspace rather than pinning a literal, and the crate on docs.rs is described as the latest release of a project that publishes no stable GitHub releases of its own.

The documentation split follows from the same fact. The file you read on the repository tracks the default branch, which received its last push on 2026-11-02, while the hosted crate documentation follows whatever was uploaded to the registry. If you need a stable identifier, you have to supply a revision yourself, and the instructions do not show the flag that would do it.

The packaged crate carries the Rust sources and no Python library

The Cargo manifest narrows what gets packaged with an include list of `LICENSE`, `Cargo.toml`, and `src/**/*.rs`. The Python library that the interpreter needs lives outside that set, in `Lib/`, which is managed with symlinks. On a Windows clone those symlinks are not there by default, and the fix is a git setting:

git config core.symlinks true

Windows users then hit a second gap. The interpreter is pointed at it through an environment variable: set `RUSTPYTHONPATH` to the `Lib` path inside the project directory, for example `C:\RustPython\Lib` when the checkout lives at `C:\RustPython`. Two configuration steps, one of them global to a repository, stand between a fresh Windows clone and a working standard library, and neither is optional the way it is on macOS and Linux, where the symlinks resolve on their own.

On Windows the release flag prevents a stack overflow, not slow code

The one-command smoke test carries a platform note attached to the flag itself:

$ cd RustPython
$ cargo run --release -- -c 'print("Hello, RustPython!")'
Hello, RustPython!

The documentation states that `--release` is needed to prevent a stack overflow on Windows. So on that platform a debug build is not merely slower, it fails before it prints anything, and the flag you would normally drop while iterating becomes the one that keeps the interpreter alive. On the interactive path the same flag appears:

$ cargo run --release
Welcome to rustpython
>>>>> 2+2
4

The prompt itself is five chevrons rather than the familiar three, a small but useful signal that you are not sitting in CPython's REPL and that familiar habits around history, exit, or indentation may not transfer unchanged.

venv is the packaging workaround, not a convenience

The reason the virtualenv instructions exist is stated in one line: RustPython does not currently provide a well-packaged installation, and using venv helps to use pip more easily. So the environment is not a nicety for isolating dependencies, it is the missing installer:

$ rustpython -m venv <your_env_name>
$ . <your_env_name>/bin/activate
$ python # now `python` is the alias of the RustPython for the new env

Inside the activated environment the `python` name points at RustPython, which is what makes the pip instructions downstream work at all. Expect to create one per project the way you would with a system Python, and expect the alternate route through conda to be a second class path: the conda-forge package can be installed, but the documentation marks it as not officially supported and possibly out of date.

TLS arrives as a feature matrix, and the default already has one

The default feature set is a long list that already contains `ssl-rustls-aws-lc`, which builds on the `ssl` and `ssl-rustls` features. That makes the instruction to enable the `ssl` feature before installing pip a step you only need when you have turned the defaults off, such as in a WASI build, and a reader who follows it in a default build is changing nothing. Embedders have a different path: the provider-agnostic `ssl-rustls` feature lets them install their own rustls crypto provider, with a FIPS variant and an `ssl-openssl` replacement available.

The OpenSSL routes carry a real toolchain bill. `ssl-openssl-vendor` compiles OpenSSL for you but needs a C compiler, perl, and `make`, or you install OpenSSL yourself on Windows. OpenSSL version 3 is the version expected and tested in CI, and older versions may not work at all.

The WASI build starts from no default features at all

The WASI command line turns the defaults off and then names what it wants:

cargo build --target wasm32-wasip1 --no-default-features --features freeze-stdlib,stdlib --release

What that discards is longer than what it restores. `threading`, `stdio`, `importlib`, `host_env`, `mimalloc`, and `doc` all sit in the default list, and the WASI command re-adds only `stdlib` and `freeze-stdlib`. A WebAssembly build that prints nothing or cannot import a module is a feature selection problem, not a WebAssembly problem. The `freeze-stdlib` feature is what embeds the standard library inside the binary so it can run anywhere, and the target itself has to be present first through `rustup target add wasm32-wasip1`.

A second documented command passes only `--features="freeze-stdlib"` and omits `--no-default-features`; `freeze-stdlib` already pulls in `stdlib` through Cargo.toml, so the two forms differ in the default features, not in `stdlib`. Running the result also needs a WASI host such as `wasmer run --volume `pwd` -- target/wasm32-wasip1/release/rustpython.wasm `pwd`/extra_tests/snippets/stdlib_random.py`.

The JIT compiles only functions you mark, and needs four build tools

The just in time compiler is described as very experimental and is disabled by default, switched on through the `jit` cargo feature with `cargo run --features jit`. Enabling it changes what the build machine needs: autoconf, automake, libtool, and clang must all be installed. On a machine without them the feature flag is not an option, it is a broken build.

Even when it compiles, the scope is narrow. A function has to be decorated at runtime before its calls execute native code:

def foo():
    a = 5
    return 10 + a

foo.__jit__()  # this will compile foo to native code and subsequent calls will execute that native code
assert foo() == 15

Any function you forget to mark keeps running through the interpreter, which means a partially jitted program mixes two execution paths.

The stated goals exclude CPython bindings and compatibility shims

The project defines itself as a Python 3 interpreter following CPython 3.15.0 or later, and its two goals are a full Python 3 environment entirely in Rust rather than CPython bindings, and a clean implementation without compatibility hacks. Both choices are visible in the tradeoffs. No bindings means nothing to keep aligned with CPython's internals, and no compatibility hacks means behaviors CPython papers over may simply be absent.

The disclaimer is unambiguous about status: the interpreter can be used in interesting cases such as running Python in WASM and embedding into a Rust project, and it is not totally production-ready. Documentation is described as still in an early phase, with online docs, a user guide, and a local generation path as the options. The listed users are narrow and instructive: GreptimeDB for embedded scripting, pyckitup as a game engine, Robot Rumble as an arena competition platform, and Ruff, described as an extremely fast Python linter written in Rust. Conference talks date from EuroPython 2018 and FOSDEM 2019.

Editorial conclusion

Use RustPython to run Python inside WebAssembly, to embed scripting in a Rust application, or to read interpreter internals, and verify the standard library loads before you depend on it. Do not treat it as a drop-in CPython replacement: the project states it is not totally production-ready, and ships no stable release. If you choose the OpenSSL route on Windows, expect to install OpenSSL or a C toolchain.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. RustPython/RustPython on GitHub