Allow [replace] overrides to track versions of a replacement

[aidanhs]

This issue title is subideal, so I'll give an example.

Crate foo is 1.0.0. They don't really want to add a 5k loc build script to support people using a specific 15 year old version of solaris. Acme corp use this version of solaris and would really like to use crate foo. They would like to create a fork of foo and use it in their projects, and they'll handle tracking foo upstream and bumping acmefoo. The replacement line might look something like "foo" = { track = "acmefoo" } - any version of foo in the dependency tree will be swapped out for acmefoo.

Ecosystem divergence is prevented by making sure the upstream crate is always the source of truth of version numbers

• if foo doesn't have a version X, there is no way for the acmefoo crate to be used via replace - version numbers are taken from crates.io for foo
• as soon as a foo version X is released, acmefoo must also release X or risk build failures when cargo attempts to get acmefoo version X

Unresolved question: what happens if acmefoo ends up with a bug in their crate? How do they release a fix? Maybe this should remain an unresolved question to try and encourage these tracked replacements to be very thin.

This is not the same as #2649

[alexcrichton]

cc @wycats, an interesting use case that doesn't quite match what [replace] does today.

@aidanhs how come though [replace] couldn't be used perhaps pointing to a git repo with tags for all the versions of the replaced crate that have been published? Is it just too onerous to update that version in Cargo.toml when you want to update?

[aidanhs]

It's both onerous and prone to human error - someone adds another crate depending on a different version of foo? Hope you remembered to add a replace line! cargo update? Better check the Cargo.lock to update all the replace lines! When you're used to Cargo magically getting things right, this isn't a great experience. Note that maintaining a tracked crate like acmefoo is also a lot of work, but the effort isn't duplicated across all consuming crates.

Just to add a concrete example of where this would be useful, see sfackler/rust-openssl#434. Not wanting to be on the hook for rushing out openssl releases is perfectly reasonable, but I'm willing to tolerate being a bit behind in my own projects. In general there are plenty of cases where an idea doesn't align with the intentions of the upstream crate but it's easy to maintain a fork.

Thinking about the unresolved question (bugfixes to tracked crates), I wonder if we could abuse prerelease notation - a track line would make Cargo look for the most recent prerelease for individual versions. E.g. say the dep tree has foo = "1.2.3" somewhere, if foo was made to 'track' acmefoo then Cargo would find all acmefoo prerelease versions, i.e. 1.2.3-*, order them according to semver and lock to the most recent one. This conceptually makes some sense - one can never be certain that you've achieved the desired feature parity, so it doesn't really make sense to have a release.

[alexcrichton]

Note that for cases like native libraries this is what overriding build scripts was intended for, where you'd have your own precompiled version of OpenSSL for musl.

[aidanhs]

I have some thoughts on improvements to make that more useful which I'll think about, but it can't help if you don't have the library built (so you want to build it from scratch within a build script, like libz and libssh2, or distribute the openssl .a files).

[alexcrichton]

Right yes the purpose is to override with precompiled artifacts, not part of the normal build process (hence the .cargo/config location)

[alexcrichton]

I believe this has been "effectively added" in the sense that we've since added [patch] and are unlikely to change [replace], so closing.