fix: cargo install uses Cargo.lock for installation - #3481
Conversation
Sorry, something went wrong.
|
there's a duplicate patch / proposal in progress already |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
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 --locked to the cargo install to to force Cargo to use the packaged Cargo.lock file if it is available which should make rust hooks more reproducible.