registrystack / registrystack/registry-stack
Feature-gate the Evidence relying-party dependency in registry-breg
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 130
Description
Found in the 0.28.0 pre-release review (2026-09-08). Line references are as of main after #926.
`registry-evidence-client` and `registry-evidence-verifier` are the only two dependencies in `crates/registry-breg/Cargo.toml` (lines 227-228) without `optional = true`, so a `default = []` library build still links reqwest and tokio through the client. The always-compiled contract path imports their types: `action_evidence_contracts.rs` and `action_evidence_validation.rs` are ungated `pub mod` in `lib.rs`, and `compiler.rs:174` calls `compile_evidence` on every project compile.
Decision recorded in `products/breg/DECISIONS.md`: 0.28.0 ships the dependency unconditional; the gate is deferred to this ticket.
Proposed change:
- Make both dependencies optional behind an `evidence` feature that `runtime` enables.
- Gate the Evidence-typed contract compile behind the same feature, with a compile-time refusal (clear diagnostic) when a project declares evidence capabilities and the build lacks the feature.
- Collapse `action_evidence.rs`, `action_evidence_client.rs`, `action_evidence_config.rs`, `action_evidence_maintenance.rs` into one `action_evidence/` module tree so the feature has one gate.
Acceptance: `cargo check -p registry-breg` with default features links neither Evidence crate; `bregctl` and `breg` behave unchanged; a test proves the refusal diagnostic.
Contributor guide
Research direction
Start with crates/registry-breg/Cargo.toml lines 227-228 and lib.rs, then inspect compiler.rs:174 and the named action_evidence modules. Run cargo check -p registry-breg with default features first; done means default builds omit both Evidence crates, runtime and bregctl/breg remain unchanged, and a test verifies the refusal diagnostic for evidence capabilities without the feature.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, build-system
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100