cargo install --dry-run

[epage]

--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

[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

[PaulDance]

As long as it ends up being implemented with things I care for or that I could add easily, I don't mind, please go ahead. I simply didn't find the time for it yet.

[LuuuXXX]

hi~, If there are any good implementations and plans, I'd love to see them happen.

[PaulDance]

but 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.

Wouldn't the standard error stream's content be enough to achieve this for now, even if there wouldn't be any stability guarantee?

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.

These would be better indeed, but as you said, they might take a while. I'm therefore looking for some middle ground that could be easier and quicker to integrate in the meantime.

[PaulDance]

@rustbot claim

[epage]

Was going to comment on #13598 but as this is on more fundamental requirements, posting it here.

We have a couple different points where we can stub out behavior for dry-run

• During compilation like #13598
• During install

Install is more complete at the cost of more time to perform (and less invasive). The challenge is each user might come to dry-run with different needs. In terms of precedence, we do the full work in cargo publish --dry-run.

[epage]

@PaulDance are you still working on this?

[PaulDance]

Not at the moment, no, sorry. You can probably unassign me from here and close the PR since a full rewrite is required anyway.

[Flowrey]

@rustbot claim