Skip to content

Enable publishing the Voro crates to crates.io#81

Merged
MJohnson459 merged 1 commit into
mainfrom
worktree-enable-crates-io-publishing
Jul 15, 2026
Merged

Enable publishing the Voro crates to crates.io#81
MJohnson459 merged 1 commit into
mainfrom
worktree-enable-crates-io-publishing

Conversation

@MJohnson459

Copy link
Copy Markdown
Contributor

Enable publishing the Voro crates to crates.io so cargo install voro (documented in the README) resolves.

Changes:

  • release.toml: publish = false -> true. Both crates already release in lockstep via shared-version/consolidate-commits; cargo-release publishes voro-core first, then voro, so voro's registry dependency resolves. Corrected the now-false 'Neither crate is published to crates.io' header comment and documented the CARGO_REGISTRY_TOKEN/cargo login requirement there.
  • crates/voro/Cargo.toml: gave the voro-core dependency a version requirement alongside its path ({ path = "../voro-core", version = "0.1.0" }) — crates.io rejects path-only deps, and cargo refuses to package a workspace dep without a version. A path build still uses the local crate.
  • Added crates.io metadata to both crates: description (voro-core had none), readme = ../../README.md, keywords, categories (voro-core: database/data-structures; voro: command-line-utilities). license (MIT OR Apache-2.0) and repository were already present via workspace.package.
  • README Releasing section: documented that cargo release now publishes both crates to crates.io (voro-core first) and that this is what makes 'cargo install voro' resolve, plus the cargo login / CARGO_REGISTRY_TOKEN prerequisite.

Publish path decision: publishing runs locally from cargo release (consistent with the existing operator-driven flow where push = false and the operator pushes the tag), not from CI — the cargo-dist release.yml only builds/publishes GitHub artifacts and is left untouched. The operator needs a crates.io token in the environment.

Verification: cargo build/fmt --check/clippy -D warnings/test --workspace all pass (193 tests). cargo package -p voro-core succeeds and includes README.md + all metadata. cargo package -p voro fails locally only because voro-core 0.1.0 is not yet on the registry — the expected ordering that cargo-release handles by publishing voro-core first; removing the version requirement instead triggers cargo's 'all dependencies must have a version requirement' error, confirming the version field is both correct and mandatory. cargo metadata confirms both manifests expose valid description/readme/keywords/categories.

Note: this change enables publishing but does not itself publish; 'cargo install voro' starts working once the operator runs the first 'cargo release' with a token configured. No remaining docs claim the crates are unpublished (the only such statement was the release.toml comment; CHANGELOG.md never carried one).

The README documents `cargo install voro` as the from-source install path, but
that only resolves once the crates are on crates.io. Wire up publishing so the
command works.

- Flip `release.toml` `publish = false` -> `true`; both crates publish in
  lockstep, `voro-core` first so `voro`'s dependency resolves against the
  registry.
- Give `voro`'s `voro-core` dependency a version requirement alongside its
  path, so both a path build and a published build resolve. crates.io rejects
  path-only dependencies.
- Add crates.io-required/recommended metadata (`description`, `readme`,
  `keywords`, `categories`) to both crates; `voro-core` had no description.
- Document the crates.io publish step and the `cargo login` /
  `CARGO_REGISTRY_TOKEN` requirement in the README, and correct the now-false
  "Neither crate is published to crates.io" note in `release.toml`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016c3RHYYkoqmmedJVhpvFj1
@MJohnson459
MJohnson459 merged commit 25599d0 into main Jul 15, 2026
6 checks passed
@MJohnson459
MJohnson459 deleted the worktree-enable-crates-io-publishing branch July 15, 2026 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant