formerly pyo3-pack
Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages.
This project is meant as a zero configuration replacement for setuptools-rust and milksnake. It supports building wheels for python 3.5+ on windows, linux, mac and freebsd, can upload them to pypi and has basic pypy support.
Check out the User Guide!
You can either download binaries from the latest release or install it with pip:
pip install maturin
There are four main commands:
maturin new
creates a new cargo project with maturin configured.maturin publish
builds the crate into python packages and publishes them to pypi.maturin build
builds the wheels and stores them in a folder (target/wheels
by default), but doesn't upload them. It's possible to upload those with twine ormaturin upload
.maturin develop
builds the crate and installs it as a python module directly in the current virtualenv. Note that whilematurin develop
is faster, it doesn't support all the feature that runningpip install
aftermaturin build
supports.
pyo3
and rust-cpython
bindings are automatically detected, for cffi or binaries you need to pass -b cffi
or -b bin
.
maturin doesn't need extra configuration files and doesn't clash with an existing setuptools-rust or milksnake configuration.
You can even integrate it with testing tools such as tox.
There are examples for the different bindings in the test-crates
folder.
The name of the package will be the name of the cargo project, i.e. the name field in the [package]
section of Cargo.toml
.
The name of the module, which you are using when importing, will be the name
value in the [lib]
section (which defaults to the name of the package). For binaries, it's simply the name of the binary generated by cargo.
Python packages come in two formats: A built form called wheel and source distributions (sdist), both of which are archives. A wheel can be compatible with any python version, interpreter (cpython and pypy, mainly), operating system and hardware architecture (for pure python wheels), can be limited to a specific platform and architecture (e.g. when using ctypes or cffi) or to a specific python interpreter and version on a specific architecture and operating system (e.g. with pyo3 and rust-cpython).
When using pip install
on a package, pip tries to find a matching wheel and install that. If it doesn't find one, it downloads the source distribution and builds a wheel for the current platform,
which requires the right compilers to be installed. Installing a wheel is much faster than installing a source distribution as building wheels is generally slow.
When you publish a package to be installable with pip install
, you upload it to pypi, the official package repository.
For testing, you can use test pypi instead, which you can use with pip install --index-url https://test.pypi.org/simple/
.
Note that for publishing for linux, you need to use the manylinux docker container, while for publishing from your repository you can use the messense/maturin-action github action.
For pyo3 and rust-cpython, maturin can only build packages for installed python versions. On linux and mac, all python versions in PATH
are used.
If you don't set your own interpreters with -i
, a heuristic is used to search for python installations.
On windows all versions from the python launcher (which is installed by default by the python.org installer) and all conda environments except base are used. You can check which versions are picked up with the list-python
subcommand.
pyo3 will set the used python interpreter in the environment variable PYTHON_SYS_EXECUTABLE
, which can be used from custom build scripts. Maturin can build and upload wheels for pypy with pyo3, even though only pypy3.7-7.3 on linux is tested.
Cffi wheels are compatible with all python versions including pypy. If cffi
isn't installed and python is running inside a virtualenv, maturin will install it, otherwise you have to install it yourself (pip install cffi
).
maturin uses cbindgen to generate a header file, which can be customized by configuring cbindgen through a cbindgen.toml
file inside your project root. Alternatively you can use a build script that writes a header file to $PROJECT_ROOT/target/header.h
.
Based on the header file maturin generates a module which exports an ffi
and a lib
object.
Example of a custom build script
use cbindgen;
use std::env;
use std::path::Path;
fn main() {
let crate_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
let bindings = cbindgen::Builder::new()
.with_no_includes()
.with_language(cbindgen::Language::C)
.with_crate(crate_dir)
.generate()
.unwrap();
bindings.write_to_file(Path::new("target").join("header.h"));
}
To create a mixed rust/python project, create a folder with your module name (i.e. lib.name
in Cargo.toml) next to your Cargo.toml and add your python sources there:
my-project
├── Cargo.toml
├── my_project
│ ├── __init__.py
│ └── bar.py
├── pyproject.toml
├── Readme.md
└── src
└── lib.rs
You can specify a different python source directory in pyproject.toml
by setting tool.maturin.python-source
or in Cargo.toml
by setting package.metadata.maturin.python-source
, for example
pyproject.toml
[tool.maturin]
python-source = "python"
Cargo.toml
[package.metadata.maturin]
python-source = "python"
then the project structure would look like this:
my-project
├── Cargo.toml
├── python
│ └── my_project
│ ├── __init__.py
│ └── bar.py
├── pyproject.toml
├── Readme.md
└── src
└── lib.rs
Note This structure is recommended to avoid a common
ImportError
pitfall
maturin will add the native extension as a module in your python folder. When using develop, maturin will copy the native library and for cffi also the glue code to your python folder. You should add those files to your gitignore.
With cffi you can do from .my_project import lib
and then use lib.my_native_function
, with pyo3/rust-cpython you can directly from .my_project import my_native_function
.
Example layout with pyo3 after maturin develop
:
my-project
├── Cargo.toml
├── my_project
│ ├── __init__.py
│ ├── bar.py
│ └── my_project.cpython-36m-x86_64-linux-gnu.so
├── Readme.md
└── src
└── lib.rs
maturin supports PEP 621, you can specify python package metadata in pyproject.toml
.
maturin merges metadata from Cargo.toml
and pyproject.toml
, pyproject.toml
take precedence over Cargo.toml
.
To specify python dependencies, add a list dependencies
in a [project]
section in the pyproject.toml
. This list is equivalent to install_requires
in setuptools:
[project]
name = "my-project"
dependencies = ["flask~=1.1.0", "toml==0.10.0"]
Pip allows adding so called console scripts, which are shell commands that execute some function in you program. You can add console scripts in a section [project.scripts]
.
The keys are the script names while the values are the path to the function in the format some.module.path:class.function
, where the class
part is optional. The function is called with no arguments. Example:
[project.scripts]
get_42 = "my_project:DummyClass.get_42"
You can also specify trove classifiers in your Cargo.toml under project.classifiers
:
[project]
name = "my-project"
classifiers = ["Programming Language :: Python"]
maturin supports building through pyproject.toml
. To use it, create a pyproject.toml
next to your Cargo.toml
with the following content:
[build-system]
requires = ["maturin>=0.13,<0.14"]
build-backend = "maturin"
If a pyproject.toml
with a [build-system]
entry is present, maturin can build a source distribution of your package when --sdist
is specified.
The source distribution will contain the same files as cargo package
. To only build a source distribution, pass --interpreter
without any values.
You can then e.g. install your package with pip install .
. With pip install . -v
you can see the output of cargo and maturin.
You can use the options compatibility
, skip-auditwheel
, bindings
, strip
and common Cargo build options such as features
under [tool.maturin]
the same way you would when running maturin directly.
The bindings
key is required for cffi and bin projects as those can't be automatically detected. Currently, all builds are in release mode (see this thread for details).
For a non-manylinux build with cffi bindings you could use the following:
[build-system]
requires = ["maturin>=0.13,<0.14"]
build-backend = "maturin"
[tool.maturin]
bindings = "cffi"
compatibility = "linux"
manylinux
option is also accepted as an alias of compatibility
for backward compatibility with old version of maturin.
To include arbitrary files in the sdist for use during compilation specify sdist-include
as an array of globs:
[tool.maturin]
sdist-include = ["path/**/*"]
There's a maturin sdist
command for only building a source distribution as workaround for pypa/pip#6041.
For portability reasons, native python modules on linux must only dynamically link a set of very few libraries which are installed basically everywhere, hence the name manylinux. The pypa offers special docker images and a tool called auditwheel to ensure compliance with the manylinux rules. If you want to publish widely usable wheels for linux pypi, you need to use a manylinux docker image.
The Rust compiler since version 1.64 requires at least glibc 2.17, so you need to use at least manylinux2014.
For publishing, we recommend enforcing the same manylinux version as the image with the manylinux flag, e.g. use --manylinux 2014
if you are building in quay.io/pypa/manylinux2014_x86_64
.
The messense/maturin-action github action already takes care of this if you set e.g. manylinux: 2014
.
maturin contains a reimplementation of auditwheel automatically checks the generated library and gives the wheel the proper.
If your system's glibc is too new or you link other shared libraries, it will assign the linux
tag.
You can also manually disable those checks and directly use native linux target with --manylinux off
.
For full manylinux compliance you need to compile in a CentOS docker container. The pyo3/maturin image is based on the manylinux2014 image,
and passes arguments to the maturin
binary. You can use it like this:
docker run --rm -v $(pwd):/io ghcr.io/pyo3/maturin build --release # or other maturin arguments
Note that this image is very basic and only contains python, maturin and stable rust. If you need additional tools, you can run commands inside the manylinux container. See konstin/complex-manylinux-maturin-docker for a small educational example or nanoporetech/fast-ctc-decode for a real world setup.
maturin itself is manylinux compliant when compiled for the musl target.
Everyone is welcomed to contribute to maturin! There are many ways to support the project, such as:
- help maturin users with issues on GitHub and Gitter
- improve documentation
- write features and bugfixes
- publish blogs and examples of how to use maturin
Our contributing notes have more resources if you wish to volunteer time for maturin and are searching where to start.
If you don't have time to contribute yourself but still wish to support the project's future success, some of our maintainers have GitHub sponsorship pages:
Licensed under either of:
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.