feat: Implement print plan and basic checks for publish command

[popzxc]

This PR adds two features I found useful recently:

• Ability to perform basic checks before running cargo publish.
• Ability to just print the packages in order in which they should be published.

The first one proved handy when I had to publish a lot of crates written by different people that weren't initially meant to be published. So every so often a field would be forgotten, but I won't know about it until I'm in the middle of the publishing process.

The second one is useful for large workspaces: crates.io has pretty strict rate limits on publishing new packages, so it's actually easier to get the order in which crates should be published and then do it manually.

[pksunkara]

Thanks for the PR! Made a few blocking comments.

[pksunkara]

Does cargo publish not run these checks?

[popzxc]

It certainly does, but when publishing a workspace, if, say, 7th package has some field missing, you will only know when you're in the middle of process (when you already bumped a version, created a commit, etc). So this is not very useful for publishing individual packages, but IMHO very useful for publishing a workspace.

[pksunkara]

What do you think of running cargo's --dry-run option then instead of writing the checks on our own? That way, we can run our own --dry-run for this publish subcommand. Here's the related issue #4

[popzxc]

Unfortunately, --dry-run doesn't perform these checks, as it aborts before uploading :(
These checks are performed on the server only.

[pksunkara]

That makes sense. Let's rename the option to dry_run, keep the checks and also incorporate cargo's --dry-run. Wouldn't completely fix #4, but is a start towards it.

[popzxc]

Unfortunately, I don't think it would work -- cargo publish --dry-run does check that dependencies are published, so cargo publish --dry-run would fail for the 2nd crate in the workspace.

And without this functionality, changing the name would probably be misleading.

[pksunkara]

And without this functionality, changing the name would probably be misleading.

If we are to incorporate everything else from the cargo's dry run other than checking published dependencies, it wouldn't be misleading, right? I know that cargo-release has a dry run option.

I still think we name this option as such and work toward completing it. But, in the meanwhile, we can document it as in progress.

[popzxc]

@pksunkara that makes sense! I've reworked the implementation:

• Renamed basic-checks to dry-run.
• Changed dry-run behavior to ignore versioning and publishing.
• Added cargo build as a step together with basic_checks so that we check if package compiles at least. This is not strictly equivalent to --dry-run behavior, because AFAIU it will reuse the workspace Cargo.lock, while with --dry-run a fresh Cargo.lock is generated for the package. Also, it obviously doesn't try to use previously published packages, but I guess it's unavoidable.
• With --dry-run mode for publish, --basic-checks do not make much sense in plan subcommand, so I removed it there.
• I also made checking if package is published optional for plan subcommand, because the difference in speed is significant and you don't always want to check that.

tl;dr:

• cargo ws publish --dry-run seems to have a good enough implementation.
• cargo ws plan doesn't try to be too smart and only provides information on publishing plan.

[pksunkara]

Some minor comments.

The only other thing is I would need some tests for plan (no publishing check) and dry run (without build check).

If you can test the other parts too, great. If not, no worries since they are hard to test.

[popzxc]

@pksunkara I've implemented the requested changes.
However, unfortunately, I cannot run tests, they fail even on main branch:

failures:
    test_create_bin_2015
    test_create_bin_2018
    test_create_lib_2015
    test_create_lib_2018
    test_member_glob

create_bin ones seem to fail because # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html is missing in the output. However even if I update snapshots there, they panic because of some other error.

Do you have any advice on how to proceed here?

[popzxc]

Do you think it will work? When I checked before, cargo publish --dry-run would fail on the 2nd package, because we didn't publish the previous one. This is why I didn't supply this argument before (as mentioned here).

Probably this should be removed.

[popzxc]

Just checked, the command currently doesn't work. See an example output when trying --dry-run with fixtures/normal:

error: failed to prepare local package for uploading

Caused by:
  no matching package named `dep1` found
  location searched: registry `crates-io`
  required by package `top v0.1.0 (/home/popzxc/workspace/cargo-workspaces/fixtures/normal/top)`

I will prepare a fix and add tests.

[pksunkara]

The --no-verify was added when dry-run is enabled and that would make sure that dependencies are not checked for being published. This is how the other tools in this space are doing it too.

It was working for me in Cargo 1.75. I had a monorepo with half-published crates and all of it worked.

[popzxc]

Oh, sorry, you're absolutely right! I forgot to reinstall the binary when checking 🤦
Will revert corresponding changes in #157