Suggest cargo install url using --git

[pickfire]

Problem

Currently, someone may try cargo install https://github.com/light4/cargo-info, then I see.

    Updating crates.io index
error: could not find `https://github.com/light4/cargo-info` in registry `crates-io` with version `*`

Proposed Solution

It would be nice to see a suggestion to ask the user to run the same command with --git.

Notes

No response

[petr-tik]

As suggested here
#10522 (comment)

i would like to get some input on a heuristic that I can use to tell if a command line argument is a git-repo in disguise. This is the comment in question.

b87ae28#diff-962037da03b1549f2185f7de90ea6bf84aabfe566f3033a4d983955cb21b6bf5R527-R534

Is matching "git" in the domain enough? What about "bitbucket"? Any other providers? Can this be dynamically populated from cargo config with another repository name?

@pickfire can you please provide some input as the original reporter

[epage]

I'm trying to think of what a user might type in, valid or not,

• Valid: Crate names (identifiers, might expand to <identifier>[@<version>]
• Invalid: path (foo/bar)
• Invalid: git url, including
  • https://github.com/rust-lang/cargo.git
  • git@github.com:rust-lang/cargo.git
  • https://github.com/rust-lang/cargo
  • https://bitbucket.org/jcmoyer/rust-tictactoe/src/master/
  • https://bitbucket.org/jcmoyer/rust-tictactoe.git
  • git@bitbucket.org:jcmoyer/rust-tictactoe.git

Ideas

• We can check if the path ends in .git
• We can check for git@
• Its probably safe to assume that if its a URL that is more than a path, then its git because the likelihood of a user entering a different URL is low. If we add support for another VCS or URL use, we could expand it at that point.

[pickfire]

Is matching "git" in the domain enough? What about "bitbucket"? Any other providers? Can this be dynamically populated from cargo config with another repository name?

I think string matching probably won't work here given that alias can be done, I see two ways:

• try git clone without cloning
• just suggest it when the command fail

We can check if the path ends in .git

Not a good idea as git can work without that.

We can check for git@

That limits the scope greatly given that ssh:// and https:// (and alias) works.

What I think is when a path is invalid, maybe we can first probe git to try and clone it (given that you can use alias in git like gh: to https://github.com/), so I think the best way is to try clone (or search from a valid alias in github) without really cloning on failure to find it then suggest user based on that?

But most importantly we only suggest this when the input is invalid, so it's fine even though the suggestion may be incorrect, so we don't really have to git clone to probe it, can just suggest it when the crate name didn't work out.

[epage]

We can check if the path ends in .git

Not a good idea as git can work without that.

We can check for git@

That limits the scope greatly given that ssh:// and https:// (and alias) works.

Note that my ideas for checking .git or git@ were not meant to be mutually exclusive with anything else but clues to help give the best hint. These ideas are also predicated on the fact that most people are unlikely to hand-write a git url but copy from something.

What I think is when a path is invalid, maybe we can first probe git to try and clone it (given that you can use alias in git like gh: to https://github.com/), so I think the best way is to try clone (or search from a valid alias in github) without really cloning on failure to find it then suggest user based on that?

We probably should not make any network connections to determine what hint we should give.

But most importantly we only suggest this when the input is invalid, so it's fine even though the suggestion may be incorrect, so we don't really have to git clone to probe it, can just suggest it when the crate name didn't work out.

As I mentioned, there are other cases we should differentiate with like for paths. That is why I was suggesting the URL approach so we can differentiate between an identifier, a path, and a url and suggest --git on urls.

[petr-tik]

Invalid: git url, including

* https://github.com/rust-lang/cargo.git

* [git@github.com](mailto:git@github.com):rust-lang/cargo.git

* https://github.com/rust-lang/cargo

* https://bitbucket.org/jcmoyer/rust-tictactoe/src/master/

* https://bitbucket.org/jcmoyer/rust-tictactoe.git

* [git@bitbucket.org](mailto:git@bitbucket.org):jcmoyer/rust-tictactoe.git

What about using this crate
https://crates.io/crates/git-url-parse
and specifically the parse method to verify if the invalid argument to install is actually a git url
https://docs.rs/git-url-parse/0.4.0/git_url_parse/struct.GitUrl.html#method.parse

then our hint can use the GitUrl struct to generate the appropriate suggestion?

[petr-tik]

GitUrl manages to successfully parse all 5 URLs that you gave, but installing from git@ urls fails.

cargo install --git git@github.com:rust-lang/cargo.git
error: invalid url `git@github.com:rust-lang/cargo.git`: relative URL without a base

Replacing Url with GitUrl in cargo feels like a bigger task than this ticket and current bandwidth allows. The question is - would you be amenable to using GitUrl only to verify that the cmdline argument is indeed a valid git URL and generate a suggestion that uses https for cargo install?

[petr-tik]

What do you think about this prototype? It uses GitUrl and then normalises git@ arguments into http-based git URLs that cargo currently supports.

https://github.com/rust-lang/cargo/pull/10522/files/e045b4f94dbf6ef25529d0dbfa974cebc65bc1b1..ef7ee2c7ee9e1373ec66f04460dca1db1da7f828

[pickfire]

What do you think about this prototype? It uses GitUrl and then normalises git@ arguments into http-based git URLs that cargo currently supports.

Not sure if we want to normalize it but I think it's better to show the suggestion with the url that user was given rather than the normalized url, then the user might be surprised where did that url come from, if it's from their input then it should not be surprising.