Merge cargo-clone subcommand into cargo itself.

[fa7ca7]

#1545
Merge cargo-clone subcommand into cargo itself.
Tests mostly copy-pasted from install subcommand. I just adjusted them a little bit.
Should we refactor and merge some parts of install and clone tests?

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[matklad]

Interesting!

@dethoter am I correct that the semantics of current implementation of cargo clone is to create a directory, which contains an unpacked crate from crates.io? That is, it does not actually clone the upstream repository, so it won't be possible to do, say cargo clone regex && cd regex && git commit -m"some fix"?

I wonder what semantics we actually want here: current implementation seems more precise, in that we get exactly the source code that was uploaded to crates.io, but "checkout the real repository" seems to be a more useful one perhaps?

@joshtriplett what do you think about this? Should cargo clone just unpack the crate file from crates.io, or should it read the metadata from Cargo.toml and attempt to clone the real repository?

[joshtriplett]

@matklad I'd like to have both. I do think there's value in "download and unpack the crate", especially for crates that don't list a git repository URL. But I don't think that should be called cargo clone; cargo clone should ideally git clone the repository, for exactly the low-friction contribution use case you describe.

[fa7ca7]

@matklad you are right - in this PR cargo clone just unpacks the crate file from crates.io. This way the original implementation behaves. For your use case I see 2 options:

1. cargo-clone only
   Leave the name of the subcommand as is and adjust flags.

   • cargo clone <crate> - unpack the crate file from crates.io
   • cargo clone <crate> --git [--branch=BRANCH | --tag=TAG | --rev=SHA] - try to extract the git URL from crate's metadata and in case of success clone the repo. (note the absence of git URL during the command invocation; --git is a flag)
   • cargo clone --path PATH - copy the folder if it contains a crate

2. cargo-clone + cargo-NEW_CMD
   Where NEW_CMD = [download | get | <YOUR_SUGGESTIONS_HERE>]. Leave clone subcommand only for cloning a repo as well as add a new one for the rest things.

   • cargo clone <crate> [--branch=BRANCH | --tag=TAG | --rev=SHA] - only try to extract the git URL from crate's metadata and nothing else. In case of success clone the repo. (note the absence of --git flag at all)
   • cargo NEW_CMD <crate> - unpack the crate file from crates.io
   • cargo NEW_CMD --path PATH - copy the folder if it contains a crate

@matklad @joshtriplett does any of them work for you?

Also, I've just thought about the command duplication. Won't we have a conflict between an installed cargo-clone and embedded into cargo itself?

[matklad]

cc #2640

[matklad]

Won't we have a conflict between an installed cargo-clone and embedded into cargo itself?

The built-in would silently override the external command.

[joshtriplett]

We discussed this in the @rust-lang/cargo team meeting, and had a few bits of (somewhat fuzzy) feedback.

First: while we definitely think commands like this should exist, we're not sure that we should merge this into cargo itself rather than leaving it in the crates ecosystem. (Our apologies for going back and forth a bit on that point.) Particularly because we're not sure exactly what the set of commands should be, as evidenced by some of the back-and-forth in this and other issues about what they should do (or be named).

Second, with respect to repository-based cloning, we realized that there's way too much policy wrapped up in such a command to come anywhere close to standardizing it yet. Leaving aside issues like "is an https:// URL a git repository", there's also "should you use git clone or git hub clone -t", and many other bits of user-specific policy.

We're wondering if we should just have a cargo info $cratename that prints metadata including the git repository URL, and then it's easy to open that or paste it into a clone command yourself.

[fa7ca7]

Thank you for the reply. Feel free to close or rebase when the team commits a decision someday.

[alexcrichton]

Ok I'm gonna close this, but we can of course reconsider with the discussion points above resolved!