Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for install-upgrade #6797

Open
ehuss opened this issue Mar 31, 2019 · 4 comments

Comments

@ehuss
Copy link
Contributor

commented Mar 31, 2019

Original issue: #6667
Implementation PR: #6798
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#install-upgrade

Summary
Instead of failing when cargo install detects a package is already installed, it will upgrade if the versions don't match, or do nothing (exit 0) if it is considered "up-to-date".

cargo +nightly install foo -Z install-upgrade

Unresolved questions

  • Is it tracking the correct information? There are many other settings that could be tracked (rustc, env variables, changes in dependencies in Cargo.lock, mtime for path sources, etc). The current set was chosen to be practical and simple and should cover most use cases. Otherwise --force is intended as a workaround for more advanced requirements.
  • Should there be a way to upgrade all outdated packages? (See #6667 for more about this.)
  • Should --no-track be kept, or is there a better approach for packaging? Does it have the right behavior? See also #3316.
  • Should this be the new default? Should there be an option to disable upgrades and revert to the old behavior?
  • If a new version of a package drops a binary, should those dropped binaries be uninstalled when the new package is installed? Currently it only replaces binaries.
@gnzlbg

This comment has been minimized.

Copy link

commented May 28, 2019

Should there be a way to upgrade all outdated packages? (See #6667 for more about this.)

That's probably a different feature right? Or why would we need to resolve this as part of this one?

If a new version of a package drops a binary, should those dropped binaries be uninstalled when the new package is installed? Currently it only replaces binaries.

I think this should behave like uninstalling the package, and then installing the newer one, so that would mean that yes, this should do that. Having said this, printing a warning: ... when this happens wouldn't hurt (as long as there is a quiet mode available).

@ehuss

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2019

That's probably a different feature right? Or why would we need to resolve this as part of this one?

Yea, in my original proposal I indicated it should probably be separate. I just included it here for completeness in case people felt it was important.

I think this should behave like uninstalling the package

That sounds good to me.

@rye

This comment has been minimized.

Copy link

commented Jul 13, 2019

My perspective here is mostly that of an end-user, but having just read through the implementation PR I do have some opinions on these questions:

  • Is it tracking the correct information?

As you note, the current set (at least what is listed there) seems to me to be a pretty good set of distinguishers between versions. I was personally only thinking about versions as being criteria—this set also covers more information. It might be nice to update all installations that match the given criteria. For example, if I've installed for target A and target B of crate foo, I'd expect cargo install foo to see both targets updated, or tell the user that it wants a specific install to operate on.

  • Should there be a way to upgrade all outdated packages?

I think so, but I don't see a way to make this fit with the verbiage cargo install. I think a separate subcommand (cargo upgrade/cargo update, for example) that checks installed packages for updates and makes them happen would be best. Since the information you store has a big installs key, I think this should be somewhat straightforward.

  • Should --no-track be kept, or is there a better approach for packaging? Does it have the right behavior?

Based on the description given, I think it's just about right. For packaging, I personally am of the mind that --no-track is a good option to prevent pollution. The documentation or name could be changed; --no-track indicates to me instead that the installation will not be tracked by some analytics engine. Perhaps --no-store-installs-metadata or something more concise?

In building Docker images with Crates, I think having --no-track is a sane option; though I think the tendency is to just ignore the ~/.cargo directory entirely. So it might not be necessary, but could definitely be of use.

  • Should this be the new default? Should there be an option to disable upgrades and revert to the old behavior?

For the cargo install subcommand, I absolutely think so. This will require some education through documentation changes, but I think many users that come from other languages like JS/Ruby prefer this ergonomic over a flag that they have to pass to explicitly enable the behavior. This would also fall under the same token as that which make install users would be used to; generally install targets that I have seen in the wild will overwrite existing artifacts with no concern.

I could definitely see a cargo install --install-only or cargo install --no-upgrade that dies if something is already installed. But then again, I also think cargo install could just be assumed to install the latest version, as I don't think many users who are installing things globally via cargo install would care if a second iteration overwrites.

  • If a new version of a package drops a binary, should those dropped binaries be uninstalled when the new package is installed? Currently it only replaces binaries.

I think replacement of remaining binaries is fine, with a warning added indicating that binaries were dropped. Though, since doing so would require comparison of the former and latter states anyhow, it might just be better to uninstall dangling binaries and warn the user that you did that. This could also be toggleable behavior. (Proposal: --keep-dangling.)


There is one additional item—I would like the final version of this feature to just reuse $CARGO_HOME/.crates.toml, but with a [v2] key, if possible. I wasn't sure if this was part of the plan, but I think it'd be the cleanest end-result.

@elichai

This comment has been minimized.

Copy link

commented Aug 9, 2019

I would've preferred this as a flag like: cargo install --upgrade but this is still good, any plans for stabilization?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.