Add option to pass python version number

[JasperDeSutter]

When building through a CI pipeline, it's not possible to pass a version number that has an incremental build number to maturin build.
For my use case, the rust package has version "0.3.0", but the actual python package/wheel should receive "0.3.0.dev50". Simply renaming the file is not enough as the embedded metadata contains the version in some places (including directory name).
Passing the version would need to be dynamic - through environment variable or argument, not in a file like Cargo.toml - because this version is generated by the build pipeline.

Also note that cargo version semantics are different to python, and treats "0.3.0.dev50" as junk.

[konstin]

I think this is duplicate of #121. The short version is using semver versions, e.g. 0.3.0-dev50 instead of 0.3.0.dev50. pip and pypi are also fine with semver instead of PEP 440.

[JasperDeSutter]

It makes sense to use semver so that cargo doesn't complain, I guess this could be done for my issue as a compromise. But that doesn't solve the issue that a dynamic buildnumber generated by the build pipeline cannot be 'injected'.
One solution could be to edit the Cargo.toml file from the build pipeline. It doesn't seem like a good solution, but I don't see another workaround at the moment.
Likely something like passing a "python-bindings" argument to maturin build, or an environment variable would solve both issues at once for me.

[konstin]

I think that modifying Cargo.toml in the build pipeline is the best solution. It should be a one-liner and will e.g. also ensure that env!("CARGO_PKG_VERSION") is equivalent to the package version. I'd like to avoid adding features to cargo that cargo deliberately does not provide.

[messense]

wheel actually have a build tag part, see https://www.python.org/dev/peps/pep-0427/#file-name-convention

{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl

And bdist_wheel command has a --build-number option to specify it. We can also add it to maturin, will it solve your issue?

[konstin]

PEP 621 also commited to having a static project.version field in the metadata just like cargo's package.version, so this a won't fix from maturin's side. If you need to do this just use sed to replace the version in a previous step of the CI pipeline

[DavidAntliff]

FWIW, setuptools supports a dynamic version that can be programmatically set by setup.py very easily, via custom command line handling, or environment variable, or anything really. Maturin seems to have no such thing and delegating this to CI is only half the story. In my case I have developers who need to build the package locally with a specific version, but using sed or cargo set-version to modify the package version marks the Cargo.toml file as modified, thus makes it liable to being accidentally committed to source control, which creates its own problems.

Also, PEP 621's motivation provides for "escape hatches", such as the dynamic version, and by the look of this thread, the maturin project seems to purposefully disregard this.

Either way, I don't think it should be a "won't fix", because there's an open issue here: Maturin is non-compliant with PEP-0621 as described here.

I.e. if maturin does not support the dynamic version directive, then at the very least it should "raise an error" if a dynamic version directive is encountered.

[jonded94]

Also just chiming in since we're trying to switch over from C++ to some more Rust based libraries and stumbled over this particular issue.
I'd say it's a pretty standard and expected workflow in the Python world in general, as @DavidAntliff also already mentioned. Using mechanism that determine a version number just from git information alone allows easy, atomic releases from a non-dirty workspace and makes consuming dev builds far easier, as each of them will have a hash-specific version number automatically.

This comment also nicely explains what can go wrong in non-atomic, manual release processes.

As cargo now seems to allow version-less manifests (which I tried locally), I think there should be a somewhat easy way that maturin injects some version information on building a wheel.