cargo install --dry-run

[epage]

View all comments

Implementation: #14280

--dry-run is an important feature for commands with side effects to help

• Give users confidence in what the commands will do (e.g. what binaries will be installed)
• Offer a tool for users and developers to debug subsets of the functionality
• Allow scripts to check the status of the system

Unresolved questions

• Should we compile packages?

Testing instructions: #11123 (comment)

[weihanglo]

This is a feature to pursue. We can make it as an unstable feature behind -Zunstale-options. However, it is not really in a high priority, so label it as S-needs-mentor for now.

[PaulDance]

Just thought about this and it would seem nice indeed. My personal use case would be to be able to detect whether a package needs:

• an install: Would install <pkg>@<version>;
• an update: Would update <pkg> from <old-ver> to <new-ver>;
• or nothing: the same Already up-to-date.

or something along those lines, as long as it has the necessary information, at least these.

Indeed, if I'm not mistaken, the install command currently performs its duties linearly one package at a time if multiple are given. Therefore, when giving a good bunch of them that are already installed, the version check can take quite a bit of time and end up not starting any kind of actual installation if all are already up-to-date for example. As this specific part is mostly IO-bound, then performing it concurrently gives an easy performance boost. The option would thus enable that easily as well.

Although it not high priority for me either, as the buggy version check that I currently have based on cargo search will call cargo install on some packages just for nothing but without any consequence, I would therefore be pleased to at least attempt some things towards implementing this. The mentoring part would definitely be of use to me however, so if you have time in the near future, it would be great.

[weihanglo]

Hey @PaulDance. Thanks for being interested in this.

Thinking backwards from what users want, here is my idea that the initial version of --dry-run could have:

• How: Is it an update (replace), a fresh install, or no-op?
• What: which binary from which source is going to be installed
• Where: to where the binary will be installed

There might be somethings hard to do in the first PR, like programming interface for scripting, or checking if yanked versions will block the installation. That's fine, since we plan to put it behind -Zunstable-options (the process of adding it can be found here). It is benefical for maintainers to review the implementation, if we can break down a feature a into several small PRs. It also increases the chance to merge them sooner.

For the implementation, it might not be as easy as it looks like at first glance. It depends on how acurate we want for cargo install --dry-run. The best option we have is collecting the info after Cargo computing all the necessary build tasks.

• In cargo install, the build task computation starts from here. Down from there, the actual compilation starts from this line. After that Cargo collects the compilation results into the Compilation struct. These steps are all in one function Context::compile(). If you have an idea of refactoring, Don't hesitate. But beware, the Context::compile() function is already complicated. We should keep it simple as possible as we can.
• You might want to take a look at build-plans and unit graph features. They might be good references for this feature, as they do similar stuff: computing build tasks without excuting them.
• We care only BuildContext::roots units, as they are bins/libs requested from the command line to install.

If you have any question, find us on Zulip t-cargo or in the office hours. Cheers!

[epage]

@weihanglo I think I'm missing where you are going with talking about Context::compile. Could you clarify the connection?

[epage]

My personal use case would be to be able to detect whether a package needs:

For querying the state (needs install, needs update, updated), we have the data (crates2.json) but we a cargo install --dry-run wouldn't have the programmatic API to access that information except through whatever errors via combinations of existing flags we already provide. Waiting on #4379 for more programmatic output might take a while. I wonder if the better route would be to tie these questions into more general version management in #9527

[weihanglo]

@weihanglo I think I'm missing where you are going with talking about Context::compile. Could you clarify the connection?

To learn where Cargo will install the binaries, we need output infos that are computed in Context::compile.

[LuuuXXX]

claim first, question it later~ @rustbot claim