feat(manager/cargo): support for git dependencies

[secustor]

Discussed in #26521

^{Originally posted by richvdh January 5, 2024}

Tell us more.

https://github.com/richvdh/renovate-cargo-git-test is an example of a Cargo project with a git dependency. Cargo.lock is out of date, and can be updated with cargo update -p empty-git-lib.

Renovate reports:

{
  "baseBranch": "main"
  "config": {
    "cargo": [
      {
        "deps": [
          {
            "currentValue": "0.1.0",
            "datasource": "crate",
            "depName": "empty-git-lib",
            "depType": "dependencies",
            "lockedVersion": "0.1.0",
            "managerData": {
              "nestedVersion": true
            },
            "packageName": "empty-git-lib",
            "skipReason": "git-dependency",
            "updates": []
          }
        ],
        "lockFiles": [
          "Cargo.lock"
        ],
        "packageFile": "Cargo.toml"
      }
    ]
  }
}

My understanding, looking at the source, is that Renovate will refuse to touch any dependency that comes from a git repo. It would be great if support could be added!

Reproduction: https://github.com/renovate-reproductions/26531

[philbucher]

Hi,
This would also be very useful for me.

I noticed that git-dependencies are supported for poetry, perhaps the same concepts could be used here?

[mkniewallner]

Hi, This would also be very useful for me.

I noticed that git-dependencies are supported for poetry, perhaps the same concepts could be used here?

Planning to add support for it, being also interested by that feature (so feel free to assign the issue to me), but ideally not until #31260 is merged.

[mkniewallner]

#32235 that supports git dependencies is mostly ready, but there's one thing I'm not quite sure about in the logic (#32235 (review)) I've been told could be worth sharing here.

Basically, I had to do ab69e05 on top of the existing logic, otherwise a warning would be displayed on Renovate's dependency dashboard, as git dependencies do not have locked versions in Cargo.lock, having for instance:

[[package]]
name = "ruff_python_parser"
version = "0.0.0"
source = "git+https://github.com/astral-sh/ruff?tag=0.6.1#02c4373a4927657a8825d18ae8f0877806cd1f15"

But this means that for git dependencies, we would never use cargo update --package <name>@<locked_version> --precise <new_version>, but always cargo update, which currently is only used for cases where crate dependencies do not have locked versions.

It does seem to work fine though, as can be seen in mkniewallner/renovate-rust-git-dependencies#11, but I'm not sure if this is the expected way to treat the update of git dependencies.

Technically, using --precise also works fine if we update the version in Cargo.toml and use --package <name> instead of --package <name>@<locked_version>, for instance:

cargo update --package ruff_python_parser --precise 0.7.0

But I believe the idea of passing @<locked_version> is to make sure we update the correct version of the dependency, as in cargo, it's possible to have the same dependency on different versions in the lock file.

[rarkins]

I think we should skip that lockedVersion check one way or another - it's fully "locked" in the package file alone.

It's also important that grouping or updating git dependencies with others does not produce unwelcome/unnecessary changes. I assume that cargo update without params might update all dependencies? That would certainly be unwelcome. We ideally would do this:

• Set tag/sha in the toml
• Run a cargo command which does the minimum necessary to sync the lock file and make it correct