add a way to share Cargo.lock information

[metajack]

We would like some way for a crate to depend on libservo and inherit (in some fashion) the pinned dependencies. Currently libraries have their Cargo.locks ignored, which is the correct behavior, but there are special cases where this doesn't work, and Servo's dependence on pinned versions of nightly Rust are one of these cases.

At the Mozilla All Hands this was discussed and a cargo update --lockfile was proposed.

[metajack]

cc @shinglyu @paulrouget

[alexcrichton]

One thing which may work today (I'd have to check) is to just copy some other project's Cargo.lock into the current directory. In theory that should work just fine and the next cargo build will simply update the lock file accordingly, doing rough conservative updates where it can (and sticking to what's in the lock file if it can).

Maybe worth testing?

[paulrouget]

This is what we do as of now, and it works.

The problem is that we have to manually copy and update the lock.

[alexcrichton]

Oh awesome! In that case this should be a very easy feature to implement! We'd just need to add a flag and thread it through.

[paulrouget]

How would cargo update --lockfile work?

Let's imagine I put together a rust project that depends on the libservo crate, I want the Cargo.lock of my project to use the libservo lock file. So I would do cargo update --lockfile libservo ?

[alexcrichton]

Oh I'm thinking that you'd have a checkout of the Servo lockfile somewhere locally, so you'd do somethign like cargo update --start-from path/to/servo/Cargo.lock (or something like that)

[metajack]

Is it possible we could specify it from a dependency? So you could do cargo update --start-from servo?

[alexcrichton]

I think it may be pretty tricky to get that working. Cargo doesn't even know what the crate servo is until it's halfway through resolution, and if it found at that point a Cargo.lock it'd have to abort everything and restart. From a conceptual point of view I think it'd make more sense to take a raw file, but I can see from a UI perspective it'd be nicer to take a crate on crates.io.

[metajack]

What about putting in a git url to the project? File system is so clumsy. I don't have particular suggestions on mechanism, but I would like it not to be point to a file deep in some tree. For starters, what if you don't have servo checked out?

[tschneidereit]

Cargo doesn't even know what the crate servo is until it's halfway through resolution, and if it found at that point a Cargo.lock it'd have to abort everything and restart.

How long does it take to get to that state, for a decent-sized Cargo.toml file? If it's still (maybe even dozens of) seconds, perhaps worth considering?

I get that it's conceptually dissatisfying, but I don't think it's too hard to reason about from a user's point of view (which otherwise I'd be concerned about.)

[shinglyu]

GitHub seems to have an API to get the file [0] (not sure about other git hosting sites). Maybe we can scan for Cargo.lock in the top level directory first and then download it to the right location? We don't need to do it recursively, right? Because the top-level Cargo.lock is flattened?

[0] https://developer.github.com/v3/repos/contents/#get-contents

[dwijnand]

I wonder: is this still a requirement for libservo users?

[paulrouget]

I wonder: is this still a requirement for libservo users?

Yes.

[samyak-jain]

Is this feature open for contributions?

[alexcrichton]

I think this is still along the lines of a reasonable feature to contribute, but I don't think we know well enough what the feature should look like. The first thing to do here is to get a consensus about what the requirements are for a solution and then sketch what the solution might look like.

[epage]

See also #5332

[epage]

As this looks like a duplicate of #5332 and that one has the more interesting conversations, I'm going to close this in favor of that one. If there is a reason this should be open still, let us know!