Cargo package version from git tag

[dariocurr]

Problem

I find very useful to inject the package version from git tags, without have to specify it in a file.

When using python, I use setuptools-scm, that, as they say, extracts Python package versions from git or hg metadata instead of declaring them as the version argument or in a SCM managed file.

I believe this is very helpful and useful in CI/CD

Proposed Solution

To have a better understanding, let's make an example.
When I open a repo, I tag the branch to 0.0.1, then every commit I do, the version increases, showing the commits distance from the previous version, that is detected using the git tag. Then after 50 commits, I'll have version 0.0.1-dev50.

When a patch is ready, the branch is tagged as 0.0.2 and the counting restarts.

Notes

I'll love to contribute to achieve this feature, but I really don't have a clue where to start

[weihanglo]

Thanks for the proposal. As I understand it, pyproject.toml has two types of metadata — static and dynamic¹. Cargo doesn't have that. Cargo.toml is merely a static manifest file, quite different from pyproject.toml. I am not sure how will it work as a dynamic metadata. This should be defined before proceed.

The other questions come up to my mind:

• If I have a git repository with multiple crates, what is the expected behavior when I create a new tag? Does every crate get the same version?
• It is very likely a breaking change if a Cargo.toml has no static version. Community analytic tools will definitely be broken for a while when they cannot find version field. How do you plan to handle this transition?
• Does that mean for parsing a Cargo.toml people need to have git/mecurial or other VCS tools in their system? Can a package still compile without those tools?
• How should cargo vendor and `cargo publish change accordingly? Do they just turn a “dynamic” metadata into “static” one and continue doing in the old way?

Sorry for posting a lot of questions. This change looks quite large to me. I think perhaps we should start from drafting a pre-RFC first in Rust internal forum. For example, this pre-RFC also proposes a huge change but is pretty well-written. I'd suggest doing a similar one for this proposal.

Footnotes

1. https://packaging.python.org/en/latest/specifications/declaring-project-metadata/ ↩

[weihanglo]

Sorry I shouldn't only talk about implementation aspect. Let's step back a bit, looking into the problem you want to resolve. Drop some more questions here:

• What's the pain point without this tool when using Cargo?
• Why do you think this is helpful and useful? Can you expand more?
• Why does this feature need to be a built-in feature in Cargo?
• Are there any existing alternatives? What's the workaround at this moment?
• Can it start from an external tools or a Cargo subcommand and see how far it goes?

[dariocurr]

Thanks for your prompt reply. I will try to answer all your questions and to give more info about the flow during next weeks

[epage]

See also #6583

[WhyNotHugo]

I'm often struggling in this domain too. I use git for version control, but Cargo expects me to use Cargo.toml for version control instead of git.

Some of the pains points are:

• Each time I tag a new version, I also need to duplicate this information in Cargo.toml and Cargo.lock. Saving the same information in two places in my repository is ambiguous.
• This results in the same information being present in two places that CAN (and often do) mismatch. This is the opposite of database normalisation, and is essentially a model that allows representing invalid states.
• Assume that commit N is v1.0.0. If I build commit N+3, the version exposed by Cargo is still v1.0.0, which is incorrect. git describe should output something like v1.0.0-3-g0328ae5 in this case.
• Many libraries (e.g.: clap) know how to extract the version from Cargo, but not from Git, which means that applications that use git for version control need to just through hoops and add extra code to override the version properly.

Of course, is some situations there is not git metadata available (e.g. when using cargo package), but cargo could simply take care to copy the correct version into the packaged Cargo.toml at that point.

[weihanglo]

See the recent change making package.version field optional #12786

[epage]

#6583 explores a dynamically set version. While the original title is focused on using the command-line, the discussion has branched out to general dynamic version handling. I'm going to close in favor of that so we consider the problem holistically rather than trying to evaluate the problem from multiple different angles.