Skip to content

Commit

Permalink
Delete Cargo.lock from this repo
Browse files Browse the repository at this point in the history 
There's now a lock file upstream in rust-lang/rust so the one here isn't
actually used, and otherwise this crate is used as a dependency so the lock file
isn't respected anyway!
  • Loading branch information
@alexcrichton
alexcrichton committed Oct 18, 2017
1 parent 757c3fa commit 5c9665f
Show file tree
Hide file tree
Showing 3 changed files with 2 additions and 1,187 deletions.
2 changes: 1 addition & 1 deletion .gitignore
View file
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
/target
Cargo.lock
.cargo
/config.stamp
/Makefile
/config.mk
src/doc/build
src/etc/*.pyc
src/registry/target
src/registry/Cargo.lock
rustc
__pycache__
.idea/
Expand Down
Loading

11 comments on commit 5c9665f

@jirutka
Copy link
Contributor

@jirutka jirutka commented on 5c9665f Jan 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for tirelessly finding new ways how to make packaging Cargo for distributions more PITA… :(

@steveklabnik
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jirutka sarcasm doesn't help.

As the commit message says, this isn't actually used, so keeping it here wouldn't have helped regardless.

@jirutka
Copy link
Contributor

@jirutka jirutka commented on 5c9665f Jan 5, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the commit message says, this isn't actually used, so keeping it here wouldn't have helped regardless.

You don’t use it, that does not mean that no one else don’t use it!

I’m maintaining rust and cargo packages for Alpine Linux. It’s essential to get exactly the same source tree (including dependencies) each time the package of the same version is built. Cargo.lock contains the exact versions of all the needed crates including checksums, so when building with option --locked, I can be relatively sure that the result will be always the same.

Merging cargo into rust package and building it at once is not a good approach.

@steveklabnik
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that does not mean that no one else don’t use it!

If you used it, it would be incorrect, and not actually build, because it would have drifted from what works.

@jirutka
Copy link
Contributor

@jirutka jirutka commented on 5c9665f Jan 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pardon me? Cargo is a crate and has Cargo.toml, so why it can’t have working Cargo.lock?!

@bennofs
Copy link
Contributor

@bennofs bennofs commented on 5c9665f Feb 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just hit this in nixpkgs. Here's the reasons why I don't like this change:

  • you have to have a full rust source tree just to build cargo, so if you want to ship a newer cargo release while still holding back the rustc update that's not possible without downloading two source tarballs
  • the Cargo.lock actually is used, if you build cargo outside of the "rust distribution", which I assume quite a few os-distros do (for example, nixpkgs used to build cargo this way)
  • It makes cargo different from every other executable crate out there. Before this change, cargo was "just another rust application crate" and did not need special-casing (yes, this change does not require much special casing, but it does require some)

Can you give some guidelines on how you expect distributions to actually package cargo? For example, should cargo always be updated in lockstep with rustc, and never be built by itself? If so, that would be good to know for downstream distributions.

One solution right now for us would be to just generate our own lockfile and use that for the package, but I am not sure if that's what you intended with this change?

@alexcrichton
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bennofs the expectation is that cargo is packaged next to rustc, it's not intended to be a separate package but rather built as one unit.

@bennofs
Copy link
Contributor

@bennofs bennofs commented on 5c9665f Feb 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if rustc update is blocked for some reason, we also need to block cargo updates?

@alexcrichton
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the published version of Cargo is only intended to work with that exact version of rustc it's published with. They shouldn't be updated at different times.

@psumbera
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexcrichton can you please elaborate how can I build rustc so that cargo is also build and installed?

@alexcrichton
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@psumbera sounds like a question for IRC and/or internals? Or perhaps a rust-lang/rust issue?

Please sign in to comment.