Updating error with Cargo.lock

[alexchandel]

If I had cargo had built repos before Cargo.lock was introduced, then it fails to update them.

$ cargo build -u
The -u flag has been deprecated, please use the `cargo update` command instead
$ cargo update
A Cargo.lock must exist before it is updated

And of course cargo build fails because the packages are outdated.

This is fixed by deleting ~/.cargo. To say nothing about the inappropriate location of this folder, which should be ~/.cache/cargo, as #148 recommends.

PistonDevelopers/hematite#54 and PistonDevelopers/sdl2_window#23 are related.

[steveklabnik]

I wonder if running cargo generate-lockfile and then cargo update would work too.

[alexchandel]

I still wonder why rm -rf ~/.cargo worked.

[steveklabnik]

Killing it worked because then, the repo would have been re-downloaded, and therefore, been at HEAD. Basically, cargo did not check that your local HEAD was equal to origin/master's HEAD.

[alexcrichton]

Closing, it sounds like this is working as intended. You should not be able to generate a lockfile from a build that does not work through cargo-build as the lockfile represents a state of the build that does work.

As @steveklabnik mentioned, you can force generation of a lockfile through cargo generate-lockfile but it is not necessarily recommended.

[alexchandel]

Perhaps this should be documented somewhere, say on crates.io?

[alexcrichton]

Sadly the website documentation lags a little behind master, but we're slated to update the documentation soon!