Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo.lock updates automatically on cargo build in 1.47.0-nightly #8586

Closed
de-sh opened this issue Aug 4, 2020 · 7 comments
Closed

Cargo.lock updates automatically on cargo build in 1.47.0-nightly #8586

de-sh opened this issue Aug 4, 2020 · 7 comments
Labels
C-bug Category: bug

Comments

@de-sh
Copy link

de-sh commented Aug 4, 2020

Problem

I am currently using rustc 1.47.0-nightly (6c8927b0c 2020-07-26) to build a crate containing multiple git based dependencies. The Cargo.lock to these dependencies automatically updates as a result of change to HEAD without explicit use of cargo update -p. I expected it to not update the dependencies and use the revisions from Cargo.lock as 1.46.0 used to do.

Steps

  1. cargo build

Possible Solution(s)

Notes

Output of cargo version: cargo 1.47.0-nightly (aa68721 2020-07-23)

This asciinema makes note of how the error comes to be while building the project. Checkout side-effects mentioned as latest commit to this branch:

@ehuss
Copy link
Contributor

ehuss commented Aug 4, 2020

Can you share a little more detail on a reproduction? If you are referring to a change like you mentioned at tikv/tikv@b3f9c3325, then that is expected that when you change the URL, cargo will update the Cargo.lock for that dependency. If you need a specific git rev, you'll need to specify the rev field in the dependency.

@de-sh
Copy link
Author

de-sh commented Aug 4, 2020

Please note the updates to Cargo.lock that weren't made explicitly.

https://github.com/de-sh/tikv/commit/d4af57a5c43aa94f88551d137ee55f53aee24ef4#r41190758

The changes are clear from building on 1.46.0-nightly, which doesn't update to the HEAD of git dependencies unless explicitly told to, unlike which 1.47.0-nightly does inexplicably update to latest HEAD on merely cargo build.

@ehuss
Copy link
Contributor

ehuss commented Aug 4, 2020

Ah, I see, sorry I misunderstood. I think this is a duplicate of #8468. This should be fixed on the latest nightly. I would use at least 2020-08-02.

@de-sh de-sh closed this as completed Aug 5, 2020
@de-sh
Copy link
Author

de-sh commented Aug 5, 2020

Can you guide me as to how I can do this?

$ rustup override set nightly-2020-08-05
info: syncing channel updates for 'nightly-2020-08-05-x86_64-unknown-linux-gnu'
info: latest update on 2020-08-05, rust version 1.47.0-nightly (f9d422ea7 2020-08-04)
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download for channel nightly-2020-08-05
Sometimes not all components are available in any given nightly.

@de-sh
Copy link
Author

de-sh commented Aug 5, 2020

I have emulated the same on travis:

Maybe this is not fixed for 1.47.0-nightly unlike 1.46.0-nightly as mentioned in #8468

Reopening issue

@de-sh de-sh reopened this Aug 5, 2020
@de-sh de-sh changed the title Cargo.lock updates automatically on cargo build Cargo.lock updates automatically on cargo build in 1.47.0-nightly Aug 5, 2020
@ehuss
Copy link
Contributor

ehuss commented Aug 5, 2020

When a component is missing, there are several options for installing without that component:

rustup toolchain install nightly-2020-08-05 --force
or
rustup toolchain install nightly-2020-08-05 --profile=minimal

The rustup documentation is at https://github.com/rust-lang/rustup, and via --help on the command-line.

@de-sh
Copy link
Author

de-sh commented Aug 5, 2020

Seems to be fixed in:

  • cargo 1.47.0-nightly (2d5c238 2020-07-31)
  • rustc 1.47.0-nightly (f9d422ea7 2020-08-04)

Thank you so much for the guidance @ehuss ❤️

@de-sh de-sh closed this as completed Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

2 participants