Add a --dry-run option to cargo liner ship

[halostatue]

Description

Since build logs are very large and binstall capability is not yet present, it would be nice to see a list of what should be upgraded without immediately kicking off an install and build. This is particularly important when the next available version is outside of the version specification.

Preferred solution

The table I want to see already exists as the first output of cargo liner ship, I just want a subcommand to see it on its way.

Alternative solutions

Adding a --dry-run option to cargo liner ship would achieve the same purpose, but not be as much fun to type.

[PaulDance]

Hi again!

Yes, I've thought about this in the past. A user confirmation could also be nice.

a subcommand to see it on its way

What do you mean exactly by "on its way"? From what I understand, it would be some kind of CLI argument that would make it display the version check and nothing else, right?

a list of what should be upgraded [...] when the next available version is outside of the version specification

Does this mean that the displayed table should list all the latest latest versions available or should this version check respect the configured version requirements just like the current table?

Know that due to #8, the current version check is already the latest version, so the displayed table should suffice in this regard. After fixing that however and supposing a latest version table is really wanted, the feature described here should be made to explicitly not respect the version requirements and to inform the user of that.

--dry-run

I might go with that in a first step as this seems both simple and sufficient if only the with-requirement versions are needed. A by-default interactive confirmation could also be added, with a --yes disabling it, or the opposite with an --interactive or --confirm enabling it, depending on how we want things.

[halostatue]

Until #8 is fixed, the current table is fine. After, a separate command with a third column for the latest-latest would be nice, but that can be solved when required.

I would prefer the current automatic behaviour of cargo liner ship rather than forcing interactive by default.

That gets into a bigger question — how interactive? Does it prompt once for all upgrades or just one by one?

I'm using cargo-liner in a chezmoi workflow which I want to minimize interaction with while running (running as a spawned process, I don't think that cargo liner would properly get tty access for interactivity).

[halostatue]

a subcommand to see it on its way

What do you mean exactly by "on its way"? From what I understand, it would be some kind of CLI argument that would make it display the version check and nothing else, right?

I think I meant "a subcommand to see what is on the way".

[PaulDance]

Until #8 is fixed, the current table is fine. After, a separate command with a third column for the latest-latest would be nice, but that can be solved when required.

👌

I would prefer the current automatic behaviour of cargo liner ship rather than forcing interactive by default.

Understandable. It would be a somewhat-breaking change since it seems quite a few people use it in automated environments, but then again the additional option would serve as a counter-action that would be akin to what a lot of other package managers do, so should not come exactly as a surprise. Additionally, the usual configuration + environment + CLI triplet should also give sufficient control of it.

That gets into a bigger question — how interactive? Does it prompt once for all upgrades or just one by one?

I was thinking once for all, as it seems sufficient for a basic confirmation. If some package seems not correct, the user could always stop at the confirmation, modify the configuration for the concerned package and then start again.

It would also be degraded by #8 however, so should be better to add after fixing it.

[PaulDance]

I've now implemented a new --dry-run CLI + env + config option for ship that I think should fit the needs adequately without too much complexity. Does it look good to you? A working version is available on master. In any case, I plan on releasing 0.9 that will include it some time tomorrow.

I've also changed this issue's objective in order to close it so a step could be formally recorded. Feel free to open a new issue if and when the more specific aspects discussed here are felt needed, with a description that clarifies this with respect to --dry-run.

[halostatue]

It's more verbose than I would ideally like, but it works very nicely.

[PaulDance]

It's more verbose than I would ideally like

True. I focused on maximizing fidelity first in order to get a full dry run option that covered the original need I think, but yes, after the version check, the rest is not really necessary for what you wanted. Maybe an --only-check option that would stop everything after the version check could be added as well.

but it works very nicely

Glad to hear, that's a good start in my book 😁

[PaulDance]

This is now available as part of v0.9.0.