Add ensure option to cargo install

[k-nasa]

Description

Add 'ensure'opsion to cargo_install
Options to prevent errors when crate is already installed.

Background

#6485

I think that this issue is made up of two things.

• If it is already installed, it will terminate normally
• Check for the same thing before downloading

This PR solves the first one.
I'll add the second correspondence later.

I ended up using std :: process :: exit. I would like to ask a review if this is OK

[rust-highfive]

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

[nrc]

Thanks for the PR! I think that this should be the default behaviour and the current behaviour is wrong. I would like to change the behaviour and not require the --ensure flag (which I think would be an easy change to this PR). However, we should check with the whole team.

A wrinkle is that the current behaviour is specified by an RFC, so technically we should have an RFC to amend that. However, that seems like unnecessary process to me, but if anyone thinks we should please register a concern.

I note that changing the current behaviour is not backwards incompatible (technically) because it only affects situations which would give an error today.

So, @rfcbot fcp merge and to be precise, I'm proposing that cargo install with an already installed crate should do nothing if it is up to date and reinstall if it is not.

cc #2082

[nrc]

Trying again...

@rfcbot fcp merge

[rfcbot]

Team member @nrc has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @dwijnand
• @ehuss
• @joshtriplett
• @nrc
• @withoutboats
• @wycats

Concerns:

• interaction-with-CARGO_INCREMENTAL=1 (Add ensure option to cargo install #6595 (comment))
• up-to-date-is-hard (Add ensure option to cargo install #6595 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[ehuss]

I think there might be some edge cases to consider, but I think those can be tackled later, or during implementation/PR review. Just off the top of my head:

• cargo install --path . once will install your crate. Then you make some modifications. Then run cargo install --path . again. What should it do? Since the version hasn't changed, there's no way to detect that it should be reinstalled. I'm not sure how to resolve that. (Treat --path differently? Keep a fingerprint in .crates.toml?).
• What should cargo install foo then cargo install foo --features fname do? From a high level I would expect it to rebuild and reinstall. However, .crates.toml doesn't track features. Maybe another point for keeping some sort of fingerprint?

[withoutboats]

@ehuss in both those examples, isnt the current behavior to error? It does seem like some scenarios we should not require --forceto reinstall, but currently we always do right? This is just changing it to not exit with an error code. Perhaps another issue should be opened to consider changing those behaviors as well.

[ehuss]

Nick is proposing doing more than just changing the error code. "cargo install with an already installed crate should do nothing if it is up to date and reinstall if it is not". Maybe a little confusing, it is a different proposal from this PR. cargo install currently has no concept of "up to date". This PR takes the basic step of checking the package version, but there's more to "being up to date" than just the version. I would prefer if the above examples do not "do nothing" (which would happen if only the version is checked), since that might be surprising.

[alexcrichton]

@rfcbot concern up-to-date-is-hard

Just gonna register @ehuss's concern, I agree that's something which should be worked out before we switch the behavior.

[dwijnand]

@rfcbot concern interaction-with-CARGO_INCREMENTAL=1

#4255 ("cargo install cargo-outdated fails with CARGO_INCREMENTAL=1") popped up in today's CodeTriage email. Seemed like a potential point of concern with #6564 also temporarily on. What do people think?

[k-nasa]

It seems that there was a little time, this is still under discussion, is not it?

[ehuss]

@k-nasa I just posted a proposal on how to move forward on this at #6667. Feel free to leave any comments there, and if everyone agrees on a plan, if you are interested in working on it.

[bors]

☔ The latest upstream changes (presumably #6798) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I believe that #6798 was intended to subsume this, so closing.