Skip to content

Conversation

@huitseeker
Copy link
Contributor

c8e1833 is failing its cargo publish --dry-run --workspace because of a menial time-of-pr versus time-of-merge issue. See commit messages.

Remove readme field from Cargo.toml since the file doesn't exist and
the crate is not published (publish = false).
When miden-utils-sync is declared with default-features = false in the
workspace dependencies, cargo publish verification builds dependent crates
without the std feature, causing OnceLockCompat to not be available.

This fixes the CI failure where miden-core couldn't find OnceLockCompat
during package verification.
@huitseeker huitseeker added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Dec 30, 2025
miden-utils-diagnostics = { path = "./crates/utils-diagnostics", version = "0.21", default-features = false }
miden-utils-indexing = { path = "./crates/utils-indexing", version = "0.21", default-features = false }
miden-utils-sync = { path = "./crates/utils-sync", version = "0.21", default-features = false }
miden-utils-sync = { path = "./crates/utils-sync", version = "0.21" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something that appeared recently? IIRC, we published v0.20 VM with default features turned off for miden-utils-sync.

Copy link
Contributor Author

@huitseeker huitseeker Dec 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change establishing std for miden-utils-sync is from the late innings of #2447.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure I understand why this is happening. AFAICT, OnceLockCompat is exported from miden-utils-sync both in std and in no_std context (in no_std we export the wrapper around OnceBox). So, even with default-features = false it should work - no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, this is not reproducible for me locally. My hypothesis is that in CI, the dry-run :

  • Packages each crate independently
  • Verifies each package in isolation using a temporary registry
  • This isolated verification context appears to have different feature resolution behavior than normal workspace builds.

Nonetheless, out of an abundance of caution, I'll close this.

@huitseeker huitseeker marked this pull request as ready for review December 30, 2025 16:50
@huitseeker huitseeker force-pushed the huitseeker/publish-workflow branch 2 times, most recently from 567257b to 4458e5e Compare January 4, 2026 13:54
@huitseeker huitseeker closed this Jan 4, 2026
huitseeker added a commit that referenced this pull request Jan 4, 2026
The workspace publish dry-run fails with `unresolved import
miden_utils_sync::OnceLockCompat` during verification. This happens
because cached registry data from previous CI runs can interfere with
cargo's temp registry used for workspace dependency resolution.

During verification, cargo should use the packaged v0.21.0 from the
temp registry, but stale cache entries may cause it to resolve
against crates.io data instead (where v0.20.1 lacks OnceLockCompat).

Clear ~/.cargo/registry/{cache,index,src} before the dry-run to ensure
fresh resolution without interference from cached data.

Closes #2505
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no changelog This PR does not require an entry in the `CHANGELOG.md` file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants