Idea: Cargo git dependency commit pinning flag

tools and infrastructure cargo
1

In using a git dependency in one of my projects, I noticed that my expectation of having cargo update my git dependency was different than its current behaviour. After a short discussion in #rust, I think it's probably better to discuss it here.

Suppose you have the following dependency:

[dependencies.nanovg] git = "GitHub - Oipo/nanovg-rs: Rust-language binding for the NanoVG vector graphics library"

What this does is, upon first build of the project, it saves the current latest commit on the master branch to Cargo.lock. Every subsequent build then proceeds to use that version until a user manually runs cargo update.

However, when developing, one might want to have cargo automatically check if it's the latest version and if not, automatically update.

Furthermore, I personally think that the current way of defining a git dependency, without a specific "version" or "commit", is confusing with the current behaviour of specifying crate dependencies.

There are a couple of things going on here:

  1. Developers are not able to specify whether a git dependency should be automatically updated to the latest commit
  2. For git dependencies, one is able to not specify a commit. For crate dependencies, this is not possible, one has to define at least a wildcard for the version.

So what I'd like to discuss here is:

  • Would it be a good idea to offer a flag for not wanting to pin a dependency to the Cargo.lock version, but always update it to the latest available?
  • Would it be a good idea to harmonise the explicitness of defining a version of a crate dependency with the implicit defining a version of a git dependency?

One proposal for 1. would be to add a flag like so:

[dependencies.nanovg] git = "GitHub - Oipo/nanovg-rs: Rust-language binding for the NanoVG vector graphics library" pinning = "latest|default" #for git dependencies pinning = "latest|highest_minor|default" #for crate dependencies

Where pinning can be only one of the given options listed.

One proposal for 2. is to disallow merely specifying the git repository, but always include a commit or a wildcard, like so:

[dependencies.nanovg] git = "GitHub - Oipo/nanovg-rs: Rust-language binding for the NanoVG vector graphics library*"

This would make it more similar to how crate dependencies are specified.

2

You can specify a commit:

[dependencies]
nanovg = { git = "https://github.com/Oipo/nanovg-rs", rev = "commit_hash_here" }
3

I am well aware, but this is not what I am talking about. I want to have cargo auto-update the dependency to the latest commit, without me having to call cargo update or change Cargo.toml each time.

4

Ah, sorry, misread.

5

That’s different behavior from a crates.io sourced dependency. If you declare libc = "0.2", and compile while 0.2.1 is current, it will record 0.2.1 into your lockfile. If 0.2.2 is later released, you won’t pick it up until you tell Cargo to check for updates. The purpose is likely so that if you have a build compiling, a later point in time (with all else staying the same) won’t suddenly break your build.

This seems easily solved with an alias: alias c='cargo update && cargo build'.

4 Likes
6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.