feat: add dev_dependencies manifest section

[fischeti]

What

Adds a dev_dependencies section to Bender.yml for dependencies that are only needed to work on a package itself. They are resolved when the package is the root package and are not propagated to packages that depend on it — Cargo's [dev-dependencies] semantics.

dependencies:
  common_cells: "1.39.0"

dev_dependencies:
  my_tb_utils: { path: "../tb_utils", target: tb }

Entries accept exactly the same fields as dependencies — Git/path/revision sources, remote shorthands, target, pass_targets. Listing a package in both sections is an error. The section is spelled dev_dependencies only: every key in the manifest format is snake_case, so Cargo's kebab-case dev-dependencies is deliberately not aliased and falls through to the W03 unknown-field warning, which names the offending key.

Why

Today the only knob is target on a dependency, and as the book already notes, it only filters that dependency out of source listings and generated scripts — it does not affect resolution. Every declared dependency is still resolved, locked, and inherited by everyone downstream. There is currently no way to say "this one is mine, don't inherit it".

Design note: one section, not named groups

Deliberately a single section rather than Python-style named dependency groups. Bender already has a full target-expression language with CLI selection (-t), package scoping, and negation — a second grouping mechanism would overlap with it and raise questions like "what if group test and target: test disagree?". Target expressions give grouping for free:

dev_dependencies:
  my_vip:      { version: "0.2", target: test }
  my_tb_utils: { path: "../tb_utils", target: tb }

bender script vsim -t tb

Implementation

• config.rs — new dev_dependencies field on Manifest/PartialManifest. Dependency validation is factored into a shared closure so both sections behave identically. Manifest::root_dependencies() / root_dependency() mark every site where dev-deps legitimately enter the picture, keeping the root-only rule greppable rather than implicit.
• resolver.rs — the root manifest's dev-deps are registered alongside its regular deps and their version constraints chained into mark(). Transitive manifests are untouched, so a dependency's dev-deps are never read.
• Consumers — sess.rs (lockfile validation, topological roots, root package source group), cmd/sources.rs (pass_targets), cmd/parents.rs, cmd/fusesoc.rs.

Drive-by fix

bender fusesoc and bender fusesoc --single disagreed on the root package's depend list: the full run derives it from the shared source tree, --single reads the manifest directly. Aligned so both emit the same list.

Reviewer notes

The source-leakage contract. Bender emits one flat file list for the whole graph, so a dependency's source groups stay visible downstream even though its dev-deps are not. A package whose sources reference a dev-dependency must keep those sources behind a target consumers don't enable, or the generated file list references modules no longer in the graph.

This maps cleanly onto the convention added in #327:

• target: test — reusable VIP that consumers enable → its deps belong in dependencies
• target: tb — non-reusable testbench code consumers never enable → its deps belong in dev_dependencies

This is documented under Keeping Dev-Only Sources Consistent, but it is currently a documented contract, not enforced. Making it structural would mean dropping tb-gated sources for non-root packages — a separate, more invasive change, deliberately left out of scope here.

Behavioral consequence. As in Cargo, simulating a sub-IP's testbench from a top-level repo no longer pulls that sub-IP's dev-deps, since it isn't the root. That may warrant a --with-dev-deps <pkg> escape hatch later; happy to add it if reviewers think the PULP workflow needs it.

Backward compatibility. Older Bender versions route the unknown dev_dependencies key to the extra-field path, emit W03, and ignore it — which is exactly the correct behavior for a consumer, so this degrades gracefully.

Testing

Split by nature rather than by feature:

• Manifest parsing/validation — section separation, rejection of the kebab-case spelling, field parity with dependencies, and the duplicate-section error are pure PartialManifest::validate behavior, so they are unit tests in src/config.rs, alongside the existing ones in progress.rs and diagnostic.rs. No subprocess, no fixture.
• Graph behavior — tests/resolution.rs runs the binary against a multi-package fixture built under tests/tmp/, using only path dependencies so it needs no network. Covers root-only resolution, lockfile contents, target composition, bender parents, and a dev-dep that is also a transitive dep of a regular dep (unifies to one lockfile entry, still ranks correctly in the file list). Named for what it covers rather than for this feature, so later resolution tests have a home.

Note that tests/cli_regression deliberately does not carry this: it diffs the current binary against one built from master and asserts stdout is byte-identical, so a new manifest section fails there by construction (golden emits W03 and ignores the field; new resolves it). Its fixture stays untouched, which also means it keeps proving this PR changes nothing for manifests without dev_dependencies.

All local tests pass — 20 lib, 5 resolution, 8 pickle, 18 script. cargo fmt --check clean; clippy warning count unchanged at 16, all pre-existing.

🤖 Generated with Claude Code