Skip to content

Cargo manifests inconsistently inherit [workspace.package] fields #321

Closed

Description

@aram356

Description

Package metadata is declared inconsistently across the workspace's Cargo.toml files. There is no single source of truth for version, edition, authors, license, or publish, which makes routine maintenance (e.g. a version bump) error-prone and leaves publishing unguarded.

Current state

  • Six of the eight crates under crates/ inherit edition, version, authors, and license from [workspace.package] but not publish, and they list the keys in an inconsistent order.
  • crates/edgezero-adapter/Cargo.toml and crates/edgezero-cli/Cargo.toml are outliers: they hardcode version = "0.1.0" and edition = "2021" and declare no authors at all. A version bump would have to be applied in multiple places.
  • publish is not defined anywhere in the root [workspace.package], so every crate defaults to publishable even though nothing in CI publishes them. An accidental cargo publish is not guarded against.
  • The separate examples/app-demo workspace only defines license in its [workspace.package]; its six crates each repeat version, edition, and publish = false.
  • The edgezero new scaffolding templates generate a root Cargo.toml with no [workspace.package] section at all, so every generated crate hardcodes version / edition / publish.

Desired outcome

Define publish = false once in [workspace.package] (both workspaces, and in the generated project template), and have every crate declare exactly:

authors = { workspace = true }
edition = { workspace = true }
license = { workspace = true }
publish = { workspace = true }
version = { workspace = true }

Done when

  • Root [workspace.package] defines authors, edition, license, publish = false, and version.
  • All eight crates under crates/ inherit those five fields via { workspace = true }, in a consistent order, with no hardcoded version / edition / authors.
  • examples/app-demo's [workspace.package] defines the same fields and all six of its crates inherit them.
  • The edgezero new scaffolding templates emit a root [workspace.package] section and generated crates inherit from it.
  • cargo test --workspace --all-targets, cargo fmt --all -- --check, and cargo clippy --workspace --all-targets --all-features -- -D warnings all pass; edgezero new output still builds.

Affected area

CI / Tooling, CLI (new, build, deploy, dev)

Activity

  1. self-assigned this
    on Jul 13, 2026
  2. aram356 commented on Jul 13, 2026

    @aram356
    CollaboratorAuthor

    Heads-up that the scope of PR #322 has grown beyond this issue's original description, so the two stay in sync:

    1. Workspace package inheritance (this issue) — all crates inherit authors / edition / license / publish / version, in both workspaces and in the edgezero new templates.
    2. description on every crate — only 2 of 20 had one; the other 18 now do, with a canonical [package] key order.
    3. Rust edition 2024 migration — edition = "2024" in both workspaces and the scaffolding template (Rust 1.95 is well past the 1.85 minimum).

    The notable knock-on from (3): std::env::set_var / remove_var are unsafe in edition 2024. There were 34 test-only call sites across five crates, all inside near-identical copy-pasted RAII guards. Rather than scattering #[expect(unsafe_code)] across five crates, the PR adds edgezero_core::test_env (behind the existing test-utils feature) with shared EnvOverride / PathPrepend guards and deletes the five duplicates — leaving exactly one #[expect(unsafe_code)] in the workspace, in a file that never ships in a production build.

    This issue's "Done when" criteria are all still met; PR #322 just does more. It will close this issue on merge.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions