Semver metadata being added to Cargo version requirements

[epage]

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

If you're self-hosting Renovate, select which platform you are using.

None

Was this something which used to work for you, and then stopped?

None

Describe the problem

rust-lang/cargo#13379 updated the dependencies in Cargo.toml for cargo. For curl-sys, it updated 0.4.70 to 0.4.71+curl-8.

Cargo does not support + in version requirements

$ cargo check
warning: /home/epage/src/personal/cargo/Cargo.toml: version requirement `0.4.71+curl-8` for dependency `curl-sys` includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion

Side note: the metadata value is incorrect, +curl-8 should be +curl-8.0.0

Relevant debug logs

Logs

Copy/paste the relevant log(s) here, between the starting and ending backticks

Have you created a minimal reproduction repository?

Placeholder value, please select the correct response from the dropdown

[rarkins]

When I go to https://crates.io/crates/curl-sys then I see this:

Is that expected?

Which of these is correct?

1. Renovate should not be considering any versions with build metadata, or
2. The string Renovate updates to must include the full version, not this truncated one

[rarkins]

@Turbo87 have you considered or encountered this before?

[viceice]

we've had a similar issue with nuget datasource. we simply trim the metadata away if it's a valid semver version

[Turbo87]

@rarkins Ed is correct, the displayed snippet on crates.io is incorrect. the build metadata part should be stripped from the version requirements.

[rarkins]

I'm surprised that this is the first time we've ever seen build metadata in versions (or that someone's noticed it). I guess we need to just strip everything after the + and then deduplicate the results? (keeping the most recent one's metdata)

[epage]

Within Rust, its not used much. Where it is used is mostly -sys crate which people rarely depend on directly (instead depending on the idiomatic wrapper). I don't even remember why cargo does it.

[github-actions[bot]]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction.

We may close the discussion if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[rarkins]

I would like to fix this in Renovate, but need someone to isolate this example to a minimal repo

[epage]

Ok, I tried more specifically to reproduce what you are doing and I am getting:

$ cargo update --manifest-path Cargo.toml --package [email protected]+curl-8.6.0 --precise 0.4.72
error: package ID specification `[email protected]+curl-8.6.0` did not match any packages
Did you mean one of these?

  [email protected]+curl-8.6.0

Is that the problem you are seeing?

The --package flag is meant to specify a specific existing entry in the lockfile you are trying to manipulate. This should be a problem you run into independent of metadata because the new version isn't in the lockfile yet which has me confused as to how things worked before. I can reproduce this with other packages:

$ cargo update [email protected] --precise 1.0.7
error: package ID specification `[email protected]` did not match any packages
Did you mean one of these?

  [email protected]

To get this to work, you have to specify the existing entry's version, like the message says.

[rarkins]

Thanks, I'll take another look.

[rarkins]

In the reproduction repo, the locked version is already the same as the newest version: https://github.com/renovate-reproductions/renovatebot-27086/blob/8da0c3d41ed76c981b3ecacf5e49d15927928d48/Cargo.lock#L14-L16

From the logs we see this command:

DEBUG: Executing command (repository=renovate-reproductions/renovatebot-27086, branch=renovate/compatible)
       "command": "docker run --rm --name=renovate_sidecar --label=renovate_child -v \"/tmp/renovate/repos/github/renovate-reproductions/renovatebot-27086\":\"/tmp/renovate/repos/github/renovate-reproductions/renovatebot-27086\" -v \"/tmp/renovate/cache\":\"/tmp/renovate/cache\" -e GIT_CONFIG_KEY_0 -e GIT_CONFIG_VALUE_0 -e GIT_CONFIG_KEY_1 -e GIT_CONFIG_VALUE_1 -e GIT_CONFIG_KEY_2 -e GIT_CONFIG_VALUE_2 -e GIT_CONFIG_COUNT -e CONTAINERBASE_CACHE_DIR -w \"/tmp/renovate/repos/github/renovate-reproductions/renovatebot-27086\" ghcr.io/containerbase/sidecar:10.2.1 bash -l -c \"install-tool rust 1.76.0 && cargo update --config net.git-fetch-with-cli=true --manifest-path Cargo.toml --workspace && cargo update --config net.git-fetch-with-cli=true --manifest-path Cargo.toml --package [email protected]+curl-8.6.0 --precise 0.4.72\""

And because there's no work to do, it succeeds but has no changes to Cargo.lock. Here is the PR: renovate-reproductions/renovatebot-27086#1

@epage was it intentional that your reproduction had 0.4.0 in Cargo.toml but 0.4.72+curl-8.6.0 in Cargo.lock? It doesn't allow us to verify that updating the lock file definitely works.

[epage]

No, that was not intentional. The joy of cargo being silently maximal. I'm considering making version selection more obvious as part of a project I'm working on.

[rarkins]

In that case the fix seems to be pretty easy: #27642