feat(core): range constraints for internal dependencies

[goulvenclech]

Fixes #175 . Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

What has changed?

• crates/sampo-core/src/adapters/cargo.rs: check_dependency_constraint() using VersionReq, should_update_dependency_version() to preserve ranges and update pinned versions, ManifestMetadata helpers for constraint extraction.
• crates/sampo-core/src/adapters/npm.rs: Full npm semver constraint checker (hand-rolled, no external deps). Reads constraints from package.json, supports caret, tilde, comparators, x-ranges, hyphen ranges, OR groups. Skips workspace/file/link/git protocols and pre-release versions.
• crates/sampo-core/src/adapters/hex.rs: Full Hex constraint checker (hand-rolled, no external deps). Supports pessimistic operator (~>), comparators (==, >=, <=, >, <), and and/or conjunctions. Skips pinned versions and pre-release versions (consistent with npm behaviour). The evaluation logic is Hex-generic and reusable for future Erlang (rebar3) and Gleam support.
• crates/sampo-core/src/adapters/packagist.rs: Full Composer constraint checker (hand-rolled, no external deps). Reads constraints from composer.json, supports caret, tilde, comparators (>=, >, <=, <, !=), wildcards (*, 1.*, 1.0.*), AND (comma/space-separated), OR (||). Skips stability flags, pinned versions, and pre-release versions.
• crates/sampo-core/src/adapters/pypi.rs + pip.rs: Full PEP 440 constraint checker (hand-rolled, no external deps). Reads constraints from pyproject.toml, supports compatible release (~=), comparators (==, !=, >=, <=, >, <), wildcards (==1.2.*, !=1.*), compound AND (comma-separated). Handles extras, environment markers, URL dependencies, and PEP 503 name normalization. Skips pinned versions and pre-release versions.
• crates/sampo-core/src/release.rs: validate_dependency_constraints() — validates range constraints during release planning, errors for fixed/linked groups, warnings otherwise.
• crates/sampo-core/src/types.rs: ConstraintCheckResult enum, ConstraintViolation struct.
• crates/sampo-core/src/errors.rs: ConstraintViolation error variant.
• crates/sampo-core/src/adapters.rs: check_dependency_constraint dispatch on PackageAdapter.

How is it tested?

• cargo_tests.rs: 22 constraint validation tests + 10 range preservation tests (all dep formats).
• npm_tests.rs: 40+ tests covering caret, tilde, comparators, AND/OR ranges, x-ranges, hyphen ranges, whitespace normalisation, protocol skipping, pinned/pre-release skipping, all dependency sections.
• hex_tests.rs: Tests covering pessimistic operator (~>), comparators, and/or conjunctions, pinned/pre-release skipping.
• packagist_tests: 37 tests covering caret, tilde, comparators, AND (comma/space), OR, wildcards, whitespace tolerance, pinned/pre-release/stability-flag skipping, dev-deps lookup.
• pip_tests.rs: 32 tests covering compatible release, comparators, wildcards, compound constraints, extras/markers stripping, PEP 503 normalization, optional dependencies, post-release handling, pinned/pre-release skipping.
• release_tests.rs: 4 integration tests (range preserved, pinned updated, violation blocks fixed groups, violation warns without groups).
• types.rs: Unit tests for ConstraintCheckResult and ConstraintViolation.

How is it documented?

• crates/sampo/README.md: Added note about range constraint support in internal dependencies.
• Changeset with breaking change notice.

[sampo-s-bot]

🧭 Changeset detected

Merging this PR will release the following updates:

sampo (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

sampo-core (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

sampo-github-action (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

[goulvenclech]

Open questions :

1. Currently, constraint validation only applies to ignored packages (not in release), while ALL packages in the release have their dependency versions overwritten with exact versions (e.g., ^1.0 → 1.3.0). Ranges should be preserved when still satisfied (^1.0 stays ^1.0 for 1.3.0), and only pinned versions should be updated.
2. If constraint validation iterates all members without applying ignore rules, ignored/unpublished packages can emit hard errors (for fixed/linked groups) and block releases. Does this respects should_ignore_package philosophy?
3. With this new feature, planning will always loads Cargo metadata when any Cargo package exists, which requires a working cargo binary even for dry‑run plans... Am I happy with this new requirement?

[rafaeelaudibert]

With this new feature, planning will always loads Cargo metadata when any Cargo package exists, which requires a working cargo binary even for dry‑run plans... Am I happy with this new requirement?

The usual way to install sampo right now is via cargo install, correct? Which implies the existence of cargo in most installations.