Revert #1501 in a really roundabout way #1607
Conversation
The author of ring has chosen to yank all versions of that crate other than the most recent. This has had the effect of making it so that we cannot modify our `Cargo.toml` without breaking the build. The long term fix will be to get us on the latest version of cookie (which requires updating some unmaintained dependencies). I haven't looked into how much work that will be beyond confirming that it is not as simple as just changing the version number. Right now, this is blocking anything that requires updating an existing dependency, or adding a new dependency. So this is a quick fix to get our builds working again until we have the time to sort out updating everything between us and ring. Unfortunately, this isn't just as simple as reverting rust-lang#1501, since `[patch]` doesn't force cargo to resolve to yanked versions. It'll instead resolve to really old versions of `cookie` in an attempt to remove `ring` from our dependency tree. So I've instead had to fork cookie, and change its dependency on Ring to use what we had prior to rust-lang#1501.
I don't understand, reverting #1501 should revert Cargo.lock too, which should resolve yanked versions because they're in Cargo.lock? Can you clarify what you mean by "revert"? If I run And it builds successfully for me; I've opened #1608 with that change to see if it passes travis... Am I missing something? |
|
Try adding a new dependency |
|
Just revert it doesn't really change the situation. Our build will still pass right now, since we have a Cargo.lock with the older version. As soon as you do anything to Cargo.toml though, you will cause cargo to re-resolve dependencies and will refuse to resolve Ring. |
|
You're right that I can't update itertools on that branch, but the patch to ring was added a year ago and we've change Cargo.toml/Cargo.lock since then. So what changed now? |
|
I think ring/cookie/etc is a red herring. I think we're hitting rust-lang/cargo#5702. |
All versions of Ring except 0.13.5 and 0.14.x were yanked. |
|
That still is a cargo bug. We had a lockfile. |
|
Yes, I agree. But right now cargo will refuse to resolve if we touch Cargo.toml in any way. As I said in the PR description:
|
|
A different quick fix would be to only commit those changes to the lockfile that we want, and checkout the changes having to do with ring/cookie/etc. Can you elaborate on why adding a different patch is better than that strategy? |
|
This fix doesn't require people to edit the lockfile by hand in order to add a dependency. It puts us back in a state that we can develop as normal. |
|
Actually this PR will need to go a tad further, since we can't use |
|
I'm going to look into just updating to the latest version of cookie. I'll re-open either this with more fixes or that PR shortly. |
The author of ring has chosen to yank all versions of that crate other
than the most recent. This has had the effect of making it so that we
cannot modify our
Cargo.tomlwithout breaking the build. The long termfix will be to get us on the latest version of cookie (which requires
updating some unmaintained dependencies). I haven't looked into how much
work that will be beyond confirming that it is not as simple as just
changing the version number.
Right now, this is blocking anything that requires updating an existing
dependency, or adding a new dependency. So this is a quick fix to get
our builds working again until we have the time to sort out updating
everything between us and ring.
Unfortunately, this isn't just as simple as reverting #1501, since
[patch]doesn't force cargo to resolve to yanked versions. It'llinstead resolve to really old versions of
cookiein an attempt toremove
ringfrom our dependency tree. So I've instead had to forkcookie, and change its dependency on Ring to use what we had prior to
#1501.