GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||
GeezerVison is showing github.com — fix: cargo install uses Cargo.lock for installation by hofbi · Pull Request #3481 · pre-commit/pre-commit ConversationAccording 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
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
hofbi
commented
Uh oh!
There was an error while loading. Please reload this page.
Member
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
Author
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
|
There was an error while loading. Please reload this page.
|
@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.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.