Add option to pass python version number about maturin HOT 5 CLOSED

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.

from maturin.

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.

from maturin.

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.

from maturin.

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?

from maturin.

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

from maturin.