cargo install --reinstall?

[netvl]

Currently cargo install won't overwrite existing package if asked to install one. However, this is very inconvenient when you're testing your own binaries (after each change you need to execute two commands instead of one to get a fresh version in PATH) or if you need a binary which frequently changes upstream.

What do you think of adding a --reinstall key to cargo install command? When used, it would be equivalent to cargo uninstall <args> && cargo install <args without --reinstall>, or something like it. I remember it was discussed in the RFC on cargo install, but I didn't manage to participate in that discussion; maybe it is worth to lay out reasons why it wasn't added eventually and probably reconsider that decision, if there was one.

[alexcrichton]

Yeah the discussion on the RFC ended up reaching a point that behaving akin to "make install" was the best way forward for cargo install for now. It's certainly always possible to add this backwards-compatibly, although I think perhaps it would be cargo install --update instead of --reinstall?

For now this could probably easily be a new cargo reinstall subcommand, however.

[colin-kiegel]

It would also be nice to have something like cargo install --update-all to update all locally installed (and outdated) packages in one go.

[oconnor663]

Is there any reason not to have cargo install perform an update by default, if one is available? I think that's how most Linux package managers work. apt-get install vim will update vim, for example.

[jonas-schievink]

For my CI needs it would be nice to have an option that installs a package if it isn't installed, and otherwise performs an update to the newest version of the package (or does nothing in case it's up-to-date). That way I could more easily make Travis cache the .cargo directory and save precious compile time for cargo installed stuff.

[alexcrichton]

@jonas-schievink interesting! I suspect that would be lumped into whatever "install the most recent version" logic would be added as part of this (if added)

@oconnor663 there was some pushback on the RFC, but opinions may have perhaps changed since then.

[alexcrichton]

Now that we have a PR for this (thanks @gkoz!) let's try to drill into some of the initial pushback and see if the landscape has changed here. I believe the main objection to a flag like this is that it was pushing cargo install a bit too much towards being a package manager, which is something it's explicitly avoiding trying to do.

The RFC originally proposed a --update flag to blanket update all binaries (or update one specific binary), but the flag proposed in this issue and #2405 is somewhat different where it just allows reinstalling or replacing existing binaries.

I'm gonna highlight and cc some of comments on the original RFC that pushed back against functionality like that, but I'm curious if thoughts have changed since? Does usage of cargo install mean that your opinion has changed about --update, or does --reinstall (or --replaced) as proposed here seem bad?

• RFC: Add cargo install rfcs#1200 (comment) - @Stebalien
• RFC: Add cargo install rfcs#1200 (comment) - @jarcane
• RFC: Add cargo install rfcs#1200 (comment) - @eternaleye

Curious what others think!

[jarcane]

My main comment would merely be confusion as to what the difference between --update and --reinstall would be, semantically speaking. Perhaps "update" might mean an in-place update of any changed/recompiled binaries, while "reinstall" would mean explicitly uninstalling the old binaries before reinstalling new ones?

[CamJN]

I'd argue that adding --install crossed the line from dependency/build manager to package manager; and brought along all the associated expectations.

[eternaleye]

@CamJN
I'm not so sure it did. After all, cargo install installs:

• (mostly) static binaries
• no dependencies - installs only the binaries of the current crate
• no libraries

As a result, it fundamentally doesn't support any kind of system-wide dependency handling, package conflict management, etc. That was a design decision explicitly so as to avoid crossing that line.

@alexcrichton
I'd argue that --reinstall is problematic for the same reasons I mentioned having issues with (some implementations of) --uninstall in my earlier comment that you linked.

If you're not doing it based on what you would install, you need to install metadata, which has a number of pitfalls (which I brought up in the other thread, IIRC). If you're doing it based on what you would install, but not from the exact same repository, revision, and build config as the original, you may generate a different list of things you would install, and then fail to remove files that were installed.

I would, however, support a proposal to add an --uninstall that:

1. Is run from the exact source dir the installed binaries were built from
2. Works by generating a list of would-install files and then removing them
3. Preferably checks its work, possibly by examining the config hash that I know is in libs and I hope is in executables

From there, it would be possible to --uninstall the old, followed by installing the new. Managing the process of keeping the old source around is then an exercise for the user (as would be needed on, say, LFS when using Autotools' make install and make uninstall, which my suggestion mimics) or a proper package manager.

EDIT: Agh, forgot that the metadata thing actually happened, and does get installed. In that case, so long as this doesn't require new metadata, I have no objections as at least it doesn't make it worse. However, the fact that the metadata gets written in-place to a single file (.crates.toml), rather than per-crate files, is still very hostile to package managers, and was one of the pitfalls I explicitly mentioned 😞

[gkoz]

I should probably add that --replace proposed in #2405 is not meant as a substitute for --update: it doesn't care about versions at all and --update might still need --replace for cases of two crates installing identically named binaries.

If you're doing it based on what you would install, but not from the exact same repository, revision, and build config as the original, you may generate a different list of things you would install, and then fail to remove files that were installed.

So the proposed implementation removes the old crate completely if neither --bin nor --example is supplied.