`cargo add`: include only MAJOR.MINOR

[ordian]

Add an option (or enable by default) to add a dependency with version = MAJOR.MINOR, not MAJOR.MINOR.PATCH.

[killercup]

Why?

[ordian]

Why?

Why e.g. semver and regex are specified in this form in cargo-edit's Cargo.toml?

Usually, you want to specify a minimal required feature level, so e.g. docopt uses this model.

I would rather ask why do you want to specify the full version?

[killercup]

Good points! If adding dependencies by hand, I tend to omit the patch version, except if it's an 0.x and I know this feature was added recently, like `regex = "0.1.66"`. From a practical stand point, this is aesthetics, though: 1.2.3 and 1.2 and 1 will all load 1.4.9 (if that is the latest version), as cargo interprets this as `^1.2.3` etc. From a pessimistic stand point: 1.2.0 to 1.2.2 are probably buggy versions—why else would they publish a 1.2.3? So, let's make sure we (and hopefully als other dependencies) are using the absolutely latest version! As you can see, there seem to be good arguments for both sides—and I'd love to hear some more before deciding! Andronik Ordian <notifications@github.com> schrieb am Do. 29. Juni 2017 um 01:18:

…

Why? Why e.g. semver and regex are specified in this form in cargo-edit's Cargo.toml? [image: ] Usually, you want to specify a minimal required feature level, so e.g. docopt <https://github.com/docopt/docopt.rs/blob/master/Cargo.toml> uses this model. I would rather ask why do you want to specify the full version? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOX0xJ-m_uioA7lhD29mlL6mlAvgvEks5sIt9DgaJpZM4OIifr> .

[ordian]

From a practical stand point, this is aesthetics, though: 1.2.3 and 1.2 and
1 will all load 1.4.9 (if that is the latest version), as cargo interprets
this as ^1.2.3 etc.

I would argue that 1.2 is better than 1 because the latter doesn't specify the minimal feature set, while the former does.

From a pessimistic stand point: 1.2.0 to 1.2.2 are probably buggy
versions—why else would they publish a 1.2.3? So, let's make sure we (and
hopefully als other dependencies) are using the absolutely latest version!

Consider the following example. At some point, you add a dependency X via cargo add, let's say 1.2.1.
Later a bug in X was found. But you forgot to update the dependency. In this scenario, 1.2.1 is worse than 1.2, because 1.2 will only compile to latest version.

[killercup]

I would argue that 1.2 is better than 1 because the latter doesn't specify the minimal feature set, while the former does.

True. But you can easily argue that 1.2.3 is better than 1.2 because the latter doesn't specify the minimal level of patches that make the needed feature work while the former does :)

In this scenario, 1.2.1 is worse than 1.2, because 1.2 will only compile to latest version.

If I understand you correctly, this is false, actually. Assuming

But you forgot to update the dependency.

means you already have the dependency version pinned in your Cargo.lock, they both act the same. And cargo update will update both to the latest version that is <2.0.0. Cargo assumes ^ default, see this for details.

[ordian]

True. But you can easily argue that 1.2.3 is better than 1.2 because the latter doesn't specify the minimal level of patches that make the needed feature work while the former does :)

True, but only if you rely on the bug being fixed.

If I understand you correctly, this is false, actually.

Yeah, my brain wasn't functioning late at night. Sorry about that.

So, what you was saying in the pessimistic point is that if we have a transitive dependency X = "=1.2.0" and if we specify direct dependency X = "1.2" - it will compile, while with X = "1.2.3" it won't, forcing us to update the transitive dependency? I think, this is the rather contrived example.

In summary, I think adding an option to remove patch version won't hurt.
As well as, adding an option not to mess the whole Cargo.toml 🤣 (but that's the different issue).

[killercup]

In summary, I think adding an option to remove patch version won't hurt.

Hurt? No. But it's one more thing to maintain, and I've not yet seen a reason to bother. Are there maybe other people who also want to have this?

an option not to mess the whole Cargo.toml

No! Not an option! The default! And no --mess flag 😄 (cf. #15)

[spease]

I found this ticket because I've generally been only recording major.minor in my manual Cargo.toml files because I thought that was the recommended thing to do. The only case that I can see it changing the functional behavior is if somebody were to publish and then yank a version of a crate (eg if an optimization patch was applied, but then was found to introduce a security hole or regression) - in this case specifying the patch version would prevent the library from building if somebody just checked it out until a newer version of the library was published.

However it does change how it's read, since having three instead of two numbers suggests that the author of the library very specifically chose that patch number and newer, rather than simply choosing the latest patch of the major-minor numbers.

However, alternatively, you could look at the Cargo.toml as more of a log rather than a spec for what the author last built the library with. This seems more of a Cargo.lock duty though, and the rest of the information in Cargo.toml seems to generally be a as-minimal-as-possible defintion of what the library is and how it should be built.

EDIT: NB that I found this after running the cargo upgrade command, not cargo add, but I'd expect that the two commands would have the same convention (two or three version points).

[spease]

I ran into another issue today - using cargo upgrade more tightly constrains the dependency graph compared to using "major.minor" only. I had to step back serde and tokio_core by a version (eg 1.0.38 to 1.0.37) because of dependent libraries that this conflicted with.

[daboross]

I would definitely appreciate an option in cargo add and cargo upgrade to stick to minimal-information specification.

It's a very small wart, but I prefer to keep all of my dependency versions as 0.4 or 1 rather than specifying more detail and thus end up manually editing Cargo.toml after every use of a cargo-edit command to remove the minor and patch versions.

[YaLTeR]

Tried cargo upgrade for the first time today and I'm also one of these people who would prefer it to stick to 1 and 0.4 rather than major.minor.patch. 😃

[shepmaster]

I'll chime in as being in favor of cargo-edit maintaining the most specific version number possible. I'm happy that it uses the current patch level...

In fact, I'd actually love it if there was a way to walk backwards in versions to find the earliest usable / compatible version of a dependency so that my requirements are the most flexible for the people using my crate.

[YaLTeR]

Finding the earliest version is most certainly a bad idea because:

• it will be missing potential bug fixes and security patches;
• if it's a -sys crate or if it transitively depends on a -sys crate, and some other dependency of the user of your crate depends on a newer version of that -sys crate linking to a newer version of the native library, they won't be able to build their library since cargo will refuse linking in two different versions of the native library. I hit this one with openssl, one of my crate's dependencies was outdated and transitively depended on an old openssl-sys and another of my crate's dependencies had even its earliest version depending on a newer openssl-sys. I found no way out of the situation and had to drop the idea I had which involved that newer dependency.

[shepmaster]

@YaLTeR I disagree with your assessment because it seems to not take into account Cargo's resolution logic.

If my crate A relies on libc 0.0.1 and another crate B relies on 0.0.2, a third crate C depending on both A and B will use 0.0.2 just fine. The user gets the maximal bug fixes possible.

Putting 0.0.1 in the Cargo.toml does not require that specific version will be picked, just one semver-compatible with it. Refer to the Cargo docs for the full list of operators you can use to express your crate's version constraints. For example, twox-hash is compatible with rand 0.3.10, 0.4.x, and 0.5.x because the API surface it needs hasn't changed in those versions. There's no reason for me to be incompatible with another crate that requires rand 0.4 and force the user to upgrade to 0.5.

and another of my crate's dependencies had even its earliest version depending on a newer openssl-sys

That's the problem that I'm advocating for avoiding. If that crate was compatible with both the older and newer versions and specified it in the Cargo.toml, you wouldn't have had the problem in the first place.