Cargo-edit: `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? :trollface:

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 [e-mail] 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: :trollface:]

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
https://github.com/killercup/cargo-edit/issues/126#issuecomment-311818430,
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 :rofl: (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.

[YaLTeR]

Hmm, yeah, good point. Is there a way to force a crate with a requirement like twox-hashes to use a specific, not latest version of the depentent crate?

[shepmaster]

a crate with a requirement like twox-hashes

In a project that uses twox-hash, and a side dependency, Cargo will pick multiple versions (for whatever reason), but you can choose to unify them:

```
$ cat Cargo.toml
[dependencies]
twox-hash = "1.1.1"
rand = "0.4"

$ cargo tree
ex v0.1.0 (file:///private/tmp/ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.5.5
├── libc v0.2.43 (*)
└── rand_core v0.2.1

$ cargo update -p rand:0.5.5 --precise 0.4.3

$ cargo tree
ex v0.1.0 (file:///private/tmp/ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.4.3 (*)

[daboross]

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.

If this behavior is provided, I would be happy to not have support MAJOR.MINOR w/o patch.

---

Until we have that, though, I'm going to keep pushing for the option to exclude patch and possibly minor versions.

The main reason I remove the patch is that it's fairly arbitrary. 99% of the time it's just whatever patch version was the latest when I added the dependency. It usually doesn't even represent the features used, since I could easily end up depending on newer features without updating the patch version - I'd only update the actually used version in Cargo.lock. I'd never update the patch versions in any case as that creates commits and churn for no reason! Someone using cargo update on the end project will get the latest compatible version of all of my dependencies anyways.

I prefer to list the least-specific which still has semver information because further information (MINOR version if MAJOR > 0, or PATCH if MAJOR.MINOR > 0) is at best useless, and at worst outright incorrect.

[shepmaster]

I could easily end up depending on newer features without updating the patch version

I recommend adding a line to your CI to prevent this:

cargo +nightly -Z minimal-versions test

[shepmaster]

version in Cargo.lock

I don't think I've stated this explicitly, but I'm mostly concerned with libraries. For binaries it doesn't seem like like it really matters what you put in your Cargo.toml because there is a Cargo.lock.

[daboross]

@shepmaster

I really should get into the habit of using minimal-versions. Just haven't updated CI configs since it became a thing. Thanks for mentioning that.

If we get that and "update to minimal version which still compiles & passes tests" then I'd be good fully abandoning this.

I was considering binary crates as well only because I follow the same principal of excluding patch versions for them, and this issue is also a problem for them. Yes, it doesn't matter as much what's in Cargo.toml, but that's even more reason to not include unnecessary and semi-arbitrary versions.

[YaLTeR]

Another concern I have with versions like in the twox-hash example: you're probably developing and testing the crate on the latest crate version (rand 0.5 in this example), so you can accidentally start using an API that wasn't covered by earlier versions (0.3 or 0.4) without noticing it. Does that mean you now essentially need to test on every combination of every version of a dependency like that? @shepmaster

EDIT: also why was this marked wontfix?..

[shepmaster]

you're probably developing

Yep, most likely

and testing the crate on the latest crate version

See my previous comment for one way to test this.

Does that mean you now essentially need to test on every combination of every version of a dependency like that?

Because semver is a human construct and not something mandated by the compiler, technically yes, you would always need to test with every possible version to be sure. I take a more practical approach and trust that other developers get semver right most of the time.

Note that this is already a problem you could experience. If you put itertools = "1.0" in your Cargo.toml, as suggested by this issue, then you are saying that your code works with 1.0.0, which seems more likely to be incorrect than itertools = "1.2.35". The current behaviour, of picking the current version, has the benefit that your code was tested with the version of the crate you specify at one point in time.

Most CI setups ensure that you work with the newest versions of every possible crate (since the lockfile isn't committed, you re-resolve on every run). It's possible to check for the oldest version of every possible crate via -Z minimal-versions. I don't know of any way to check every permutation 😉

[YaLTeR]

I take a more practical approach and trust that other developers get semver right most of the time.

Yeah, but in case of a requirement like >= 0.3, < 0.6 it's perfectly valid for, e.g., 0.5 to add some new API which you might start using without realizing it wasn't available in 0.3. I suppose -Z minimal-versions is of help here indeed.

[ghost]

Wanted to follow up on this as its getting a little old to keep manually needing to remove the revision from all the dependencies in my Cargo.toml file. Are there any plans to support ignoring it and allowing just major.minor versions in this crate?

[ordian]

I don't have time to work on this, but can review a PR if someone wants to implement this.

[ghost]

I had a thought for all on this thread. In addition to the major.minor specification or limit, would it also help to have an option to do wildcards?

[pwoolcoc]

I've opened a possible solution to this, I'd appreciate comments from maintainers as well as anyone interested in this feature

[spease]

I think this would be better done on a per-project basis or via command-line flag when you add or upgrade something.

I think this would most likely be due to project policy of the project adding the dependencies; or the project which is being depended on. Some projects may worry more about backwards compatibility than others and adhere to it or track it better.

Different users opens the door to the possibility that one user will get a different result with cargo upgrade than another user or the CI unintentionally and this could cause needless churn especially for projects that take contributions from incidental maintainers. Especially if each developer works on multiple projects which have different policies as to how they want to manage their .toml.

[shepmaster]

via command-line flag when you add or upgrade something

I agree. A key reason is how Cargo treats 1.x.y vs 0.x.y.

• If I specify foo = "1.1", that includes 1.1.0, 1.1.1, and 1.99.99.
• If I specify foo = "0.1", that includes 0.1.0, 0.1.1, but not 0.99.99.

---

Over the past few days, I've had a few unrefined thoughts about this...

• I really wish that the Rust ecosystem pushed harder on minimal dependencies for libraries.
• This applies to both versions and features
• I'd actually want cargo add to pick the minimal set of version/features that works for my code
• Considering I usually add the dependency before I write the code, that could be hard
• We should use more complicated version restrictions more often. For example, having the restriction like ^1.2.19, ^1.3.4, ^1.4 shouldn't be strange for us to see (although this relies on libraries actively maintaining concurrent releases)