Repository navigation
build: make the workspace publishable on crates.io as hypercolor - #346
Merged
Merged
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. 🧰 Additional context used📚 Code guidelines (1)No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
⛔ Files ignored due to path filters (1)
📒 Files selected for processing (90)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe PR renames the CLI Cargo package, updates internal dependency versioning and publication metadata, and changes the locations used for bundled attachment templates and the OpenRGB detector table. ChangesCLI package rename
Cargo release metadata
Bundled data paths
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Other Merge Risk: ⚪ Minimal · up to The package rename, release metadata, and bundled-data paths appear aligned; the PR is mergeable after normal checks. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The inspected changes preserve the CLI library identity, exclude installer-only packages from registry publication, and retain version verification before release tagging. No introduced security vulnerability was established. Publication controls and complete build-credential isolation remain unverified, so minimal risk cannot be concluded. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 12 functions across 9 files. (26 skipped: 26 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Comment |
The crates.io name `hypercolor` is unclaimed, and `cargo install hypercolor` should install the `hypercolor` binary. Rename the package in crates/hypercolor-cli from hypercolor-cli to hypercolor; the directory keeps its name. The library target is pinned to `hypercolor_cli` so every `use hypercolor_cli::` path stays valid, including extension crates that build on `run_with_extensions`. A downstream workspace that names the dependency `hypercolor-cli` needs `package = "hypercolor"` on that entry and nothing else. Every `-p hypercolor-cli` and `--exclude hypercolor-cli` in the justfile, CI workflows, installer scripts and the guest proof now names the new package. The packaging tests assert the new strings, one of them newline-terminated so a revert to the old name cannot pass it as a prefix. The crate README, which becomes the crates.io page, says the CLI drives a separately running daemon. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hypercolor-openrgb-host included data/openrgb/detectors.toml and hypercolor-core's build script embedded data/attachments/builtin, both from outside their crate directories. A crates.io tarball carries only the crate, so openrgb-host failed to compile from its package and core compiled with an empty attachment catalog: the build script skipped a missing folder without a word. Each file set now lives in the one crate that reads it: crates/hypercolor-openrgb-host/data/detectors.toml and crates/hypercolor-core/attachments/. No other code reads either path. Core's build script now fails when the folder is missing or holds no templates, so an empty catalog can no longer ship silently, and the path test checks the folder exists. Specs that cite the old paths follow. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
crates.io resolves dependencies by version, so a path-only dependency blocks `cargo publish`. Give every internal hypercolor dependency an explicit version: the 33 entries in [workspace.dependencies] and the 12 direct path dependencies in core, daemon, driver-builtin, hal, tui, windows-gpu-interop and windows-telemetry. Path-only dev-dependencies stay as they are; cargo strips them from the published manifest. set-version.ts now stamps those requirements alongside the workspace version and verifies they agree, scanning the crate manifests in a stable order so a new internal dependency is stamped without editing the script. A stale requirement would otherwise publish a crate that asks for the previous release of its siblings. RELEASING.md lists the new stamp. Three crates stay off crates.io. hypercolor-daemon embeds protocol/websocket-v1.descriptions.json from outside the crate. hypercolor-app's Tauri manifest bundles the web UI and installer scripts from outside the crate. hypercolor-windows-helper only makes sense as the signed build the installer ships. Nothing published depends on any of them; the CLI's daemon dev-dependency is path-only and stripped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hyperb1iss
force-pushed
the
nova/crates-io-publish
branch
from
October 3, 2026 16:55
0946fdc to
61661fe
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
The workspace can now be published to crates.io, with the CLI as the
hypercolorpackage so thatcargo install hypercolorinstalls thehypercolorbinary. Nothing is published by this PR.crates/hypercolor-clinow publishes ashypercolor. Its library keeps the namehypercolor_cli, so every existing import and every extension crate built onrun_with_extensionsstill compiles. Every-p hypercolor-cliin the justfile, CI and installer scripts now nameshypercolor.data/, outside both crates. Packaged on its own, openrgb-host failed to compile. Core still compiled, but with an empty attachment catalog, because its build script skipped the missing folder without a word. Both data sets now sit inside their crates, and core's build script fails if the templates are missing.set-version.tsstamps those versions on each release. Three crates stay off crates.io:hypercolor-daemonprotocol/websocket-v1.descriptions.jsonfrom outside the cratehypercolor-apphypercolor-windows-helperNothing that gets published depends on these three. The CLI's dev-dependency on the daemon is path-only, so cargo strips it from the published manifest.
Why
None of our Rust crates are on crates.io, and the
hypercolorname is still unclaimed there. That putscargo install hypercolor, docs.rs pages and lib.rs listings out of reach. Publishing needed the rename, versioned internal dependencies, and crates that compile from their own tarballs.Verification
just verifypasses locally (Rust fmt + lint + test)just denypasses (required for dependency or license changes)just ui-testandjust ui-buildpass (required forcrates/hypercolor-ui/)just sdk-lint,just sdk-check, andjust sdk-buildpass (required forsdk/)just python-verifypasses (required forpython/)just compat-checkpasses (required fordata/drivers/vendors/*.toml)just docs-buildpasses (required for docs or README changes)cd docs && zola checkpasses (required for docs link/content changes)scripts/orpackaging/)just e2e-buildpasses with the normal Servo stack (required for daemon/UI/effect integration changes)just e2e-build-cpupasses when validating the CPU smoke fallbackjust e2epasses against the Servo stack (required for end-to-end behavior changes; starts daemon/browser)I ran targeted gates in place of the full
just verify, and no dependency versions changed. The only doc edits are crate READMEs, specs anddocs/development, none of which are in the Zola site.cargo publish --workspace --dry-run --lockedon the committed tree packaged and verified 39 crates and exited 0, with no--allow-dirty. Verifying means each crate compiled from its own tarball, so this is the check that caught the out-of-crate reads.hypercoloris among the 39.cargo check --workspace --locked,cargo fmt --all --check, and clippy with-D warningson core, openrgb-host andhypercolorall pass.cargo test -p hypercolorall pass.bash -nand the justfile parses. PowerShell isn't installed here; each.ps1edit is a single string literal.git archiveexports.Notes for reviewers
hypercolor-clineedspackage = "hypercolor"on that entry, and itsuse hypercolor_cli::lines stay valid. The private hypercolor.lighting repo also has one-p hypercolor-cliin its managed-update e2e script and needs a lockfile refresh.hypercolorlinks hypercolor-core, socargo install hypercolorwould build 26 internal crates. On Linux it would also need the ALSA, PipeWire, libclang and libjpeg-turbo development headers thatalsa-sys,pipewire-sysandturbojpeg-sysbuild against, and most machines would fail without them. The CLI only uses core's config path helpers and mDNS daemon discovery, so a follow-up moves those out and makes the CLI a thin API client before anything is published.include_str!reaching outside a crate could slip back in. The publish workflow that comes with the first release should run it on every PR that touches a manifest orbuild.rs.protocol/websocket-v1.descriptions.jsonstays put for now because all 17 in-flight branches edit it. Moving it into the daemon crate is the path to publishing the daemon later.🤖 Generated with Claude Code
Summary by CodeRabbit
Updates
hypercolor, including through platform installers and release builds.Documentation