Phantom dependencies

[CAD97]

@afetisov

Well why is libc = "0.1" still unyanked then?

Because the publishers haven't seen any necessary reason to do so. Just because there is sufficient justification does not necessarily make doing so necessary. It also doesn't cover the entire 0.1 line either, anyway.

@afetisov

E.g. secrets 1.2 uses libc = "^0",

I honestly thought crates had forbidden = "0" as well...

@afetisov

@CAD97

they underconstrained it initially out of some principle of e.g. only specifying the semver minor version

According to the semver spec, addition of new backwards-compatible APIs requires incrementing the minor version.

The point about lockfiles + time leading to the same result is the more important part of the argument, anyway.

@afetisov

Also, people with a lockfile don't need any minimal-dependencies, they already have a working configuration. It is exactly when you want to upgrade some of the dependencies when things go downhill.

Where "upgrade some of the dependencies" includes "adding a new dependency". Scenario:

# downstream
[dependencies]
serde = "1.0.100" # lockfile with this version, everything works

# time passes...

# yourlib
[dependencies]
serde = "1" # but you use features added after 1.0.100

# time passes ...

# downstream
[dependencies]
serde = "1.0.100" # lockfile still has this version
yourlib = "1" # oops, now yourlib is trying to use a too-old version of serde

@afetisov

That's [just testing minimal-versions] just wishful thinking. [...] All kind of things can break and change in incompatible ways between different crate versions.

But as you yourself said, people with a lockfile have a working configuration. The point of testing on minimal-versions is that when they add a dependency on your crate, it also results in increasing the version of the crates you use to the versions you need.

@afetisov

But maybe it's better to extend the syntax of [patch] to support overriding transitive dependencies?

[patch] already works like this. The point of [phantom-dependencies] being separate is that it's inheritable by downstream users of your library, unlike [patch] which isn't, by design.

@afetisov

This makes me doubt that crude patching of dependencies for libraries makes any sense and will help in a meaningful way.

It does help in one measurable way: minimal-versions correctness. And my underlying point is that minimal-versions correctness isn't only about using minimal version resolution, it's also about normal application of time resulting in having old library versions in use. Yes, crate authors making mistakes happens, but the point is to have some attempt at locally communicating necessary versions.

As to your point, it's impossible to prove that cargo add will never result in a nonworking dependency tree. But that doesn't mean we should ignore iterative steps towards making it better, even if only partially.

The goal of [phantom-dependencies] is to

• Allow -Zminimal-versions version resolution work a reasonable amount of the time when asking for recent dependencies
• Thus making it reasonable to stabilize --minimal-versions version resolution
• Thus making it easier to ask crate authors to be minimal-versions correct
• Thus removing the need to use [phantom-dependencies].

People can and do introduce direct dependency edges to get the desired effect here. [phantom-dependencies], I hope, is strictly better than status quo.

@afetisov

For binaries, this is more likely to help,

Binaries already have the mechanism to do so: the lockfile. Libraries have no mechanism to even try.