publish-job: crates.io

[Gankra]

Add a builtin publish-job for uploading to crates.io, in the same vein as the homebrew one.

Use this as a template: https://github.com/axodotdev/cargo-dist/blob/main/.github/workflows/publish-release.yml

(If there's a predefined "publish to crates.io action" that does what we want it's fine to use that instead)

Notes:

• do the publish_prerelease == true check that publish-homebrew does
• need to select dependent libraries in the workspace to publish based on the packages to publish, and publish them in order
  • some may already be published, that's ok
• user needs to set secrets.CRATES_TOKEN for us to use in env: CRATES_TOKEN: ${{ secrets.CRATES_TOKEN }}
• may want to support publishing to alternative registries from crates.io
• do not need to be responsible for bumping versions, cargo-dist currently assumes that's already done

[Gankra]

I am currently planning to introduce dist publish cargo as a subcommand which assumes you already have all your versions in the state you want and commited, and then:

• gets the dependency DAG (we already do that, just throw it away)
• gets the pruned topological sort that covers the Apps we're trying to publish (normal dependency graph stuff)
• iterate through it and try to publish every package, allowing for the answer to be "this is already published"

This is logic several tools include, and I roughly know how to write it from scratch.

Ideally (some modes of?) plan would also check if dist publish cargo is possible (e.g. if you depend on publish=false packages) so we can halt the release process immediately if it won't work at all. This of course can never be perfect, as e.g. you can't check if credentials for cratesio are properly setup until you try to publish, not even dry-run does it (since last i checked).

Note to self: I need to remind myself about the dev-dependency corner cases here (there's some situation where cargo complains about unpublished dev-dependencies, possibly this is just the user's problem).

[Gankra]

This command should become the template for all other builtin publish jobs. More of this, less of bespoke CI jq scripts.

[DJDuque]

Would this somehow interfere with the cargo-release workflow that is already encouraged in the cargo-dist book?

I would assume that most people using cargo-dist are already using cargo-release as part of their workflow (and let cargo-release upload to crates.io right before pushing the tag that cargo-dist needs). I am just thinking if having something like this could cause any issues for people already using cargo-release.

[Gankra]

Note to self: I need to remind myself about the dev-dependency corner cases here (there's some situation where cargo complains about unpublished dev-dependencies, possibly this is just the user's problem).

I wrote these docs covering most of the interesting/relevant info and how to work with cycles here

https://docs.rs/guppy/latest/guppy/graph/struct.Cycles.html