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

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

[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 Basic implementation for cargo install --dry-run #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

[epage]

Call for testing

cargo install --dry-run is now available and we're looking for feedback to see if this can be stabilized!

Basic steps:

Requirements:

• 1.83.0-nightly (2024-10-01) or newer (Update cargo rust#130929)

Try cargo install --dry-run on the various cargo install workflows you use

In particular, consider

• Testing under different circumstances (e.g. sources, upgrade, etc)
• If this provides the right level of fidelity you are looking for (e.g. is doing the compile helpful feedback or slow you down from what you are looking for)
• If this changed anything it shouldn't

Please leave feedback on this issue

[PaulDance]

From the few simple tests I conducted, things seem to work fine 🙂

[PaulDance]

In the case where a package needs to actually be installed or updated, the crates are in fact really downloaded and not just printed as such, right? If so, would it be possible to make it so that the same lines would be printed without actually downloading the crates or would it be too complicated to achieve in this iteration? Just looking to add a little speed without sacrificing end result information.

[epage]

We need to download to discover what bins are present.

A general question though is what level of fidelity/reporting do people want from this? For example, yank or msrv messages will only show with a compilation.

[PaulDance]

We need to download to discover what bins are present.

For the top crate or for all? I would have guessed that after downloading the requested crate and locking the dependencies, downloading the dependencies would be optional.

[epage]

True but that still runs into the second half of my comment.

[PaulDance]

My personal use case would be to determine whether something needs to be done or not. What exactly needs to happen is not of importance for me, in this first iteration at least. Fidelity is not that important for me in this regard and I would therefore be fine with Cargo only printing that it downloaded some crates while it actually did not, which should be compatible with the notion of dry run. This way, the level of reported information should stay the same while it just goes a little bit quicker.

I'll let others comment on what exactly they would need, though. For example, what happens after the downloads is not simulated at all. That part may be easier to achieve once the build plan feature lands, if I remember correctly at least.

[epage]

A middle-ground solution could be that we switch cargo install to do a cargo check --profile dev instead of cargo build --profile release. Dry-run mode will be faster while we still get all of the error reporting. Care will need to be taken in case we rely on the full results of cargo build to male sure everything still works.