fix: cargo install uses Cargo.lock for installation #3481
Conversation
|
there's a duplicate patch / proposal in progress already |
|
I could not find anything related. The only open PR related to rust that I could find is #3235, which seems to be a new feature. Also, the last update was 10 months ago. Or is there anything you are working on which you did not push yet? I am pretty sure, you understand the importance of lock files, so I wanted to make sure that this issue is fixed in time, being it with my PR or from someone else. |
|
@asottile I think I was able to find the duplicate you are referring to which should be #3163 solving #3162. Now I am a bit confused why the solution proposed either by my PR or #3163 is not what you expect? What would be your proposal to solve #3162? I am happy to support here. If you are in favor of #3235, the current solution would not add any additional challenges. And even with hard coding the locked attribute, I don't see any usecase where someone would not want to install the dependencies as in the lockfile. |
2 participants
According to the cargo documentation, cargo does not care about the lockfile by default but will recompute which versions of dependencies to use. This can lead to issues such as EmbarkStudios/cargo-deny#771 where the release of a new upstream dependency breaks an existing unchanged pipeline.
Adding
--lockedto the cargo install to to force Cargo to use the packagedCargo.lockfile if it is available which should make rust hooks more reproducible.