search

PyO3 / maturin

Build and publish crates with pyo3, cffi and uniffi bindings as well as rust binaries as python packages
https://maturin.rs
Apache License 2.0
3.95k stars 274 forks source link

Add a way to override the resultant Python package version #2163

Open DavidAntliff opened 3 months ago

DavidAntliff commented 3 months ago

Currently, maturin build uses the project.version field from Cargo.toml to version the resultant Python package.

Using this version is not recommended by the Cargo team, as it has a specific crates.io purpose, and allegedly should not be overloaded as a general "version" number for a project: https://github.com/rust-lang/cargo/issues/6583

I suggest a feature to enable override of the version number that maturin build (and maturin develop) assigns to the resultant Python package, so that alternative versioning schemes can be used.

As of today, the only way I can find to influence the Python package version seems to be to modify project.version prior to build, such as via sed in a CI script, but this does not work well for local workflows such as developer builds where a CI version number is not available. It also marks Cargo.toml as modified which can have side-effects for source control. Modifying source files is not considered proper in reproducible build environments like "yocto" or Debian package system, either, where upstream source files need to be considered authoritative.

So I suggest that there could be a new way for the environment (e.g. shell environment, or script that invokes maturin) to modify the resultant version number without modifying source files.

ia0 commented 2 months ago

Note also that if cargo build reads its own version (which is the case when writing a CLI with clap for the --version flag), then the workaround of editing the Cargo.toml doesn't work, because we want the crate version for the CLI but the Python library version for the Python package.