Proposal: Scriptable manifest as a first-class alternative to static Cargo.toml (Gradle build.gradle.kts-like)

[csdog]

Problem

Problem

Cargo.toml is static by design, which is great for reproducibility.
But it is significantly less expressive than scriptable build descriptors like Gradle's build.gradle.kts.

For advanced workflows, users often want to express build/dependency logic programmatically:

• conditional dependency declarations
• environment/profile-aware dependency sets
• reusable logic/functions for dependency groups
• computed manifest fragments
• richer multi-target orchestration in one place

Today, this usually gets pushed into wrappers (xtask, Makefiles, external scripts), while Cargo.toml remains static.
That splits build logic across tools and loses first-class Cargo UX.

Proposal

Consider introducing a first-class scriptable manifest format as an alternative to static Cargo.toml, conceptually similar to build.gradle.kts.

Examples (placeholder names):

• Cargo.kts (Kotlin-like DSL)
• Cargo.rs (Rust-based manifest DSL)
• another Cargo-defined programmable manifest language

The key idea:

1. Manifest is authored in a programmable form.
2. Cargo evaluates it in a constrained, deterministic phase.
3. The result is a normalized static manifest model for normal dependency resolution / lockfile flow.

Scope and Intent

This is not about build.rs mutating dependencies at compile time.
This is about replacing or superseding static manifest authoring with a programmable manifest authoring experience, while preserving Cargo guarantees.

Design constraints (important)

If this is considered, these constraints seem necessary:

• Deterministic evaluation (same inputs => same output)
• Reproducible lockfile semantics
• Clear input boundary (env/config/profile/target/etc.)
• Strong caching story
• Explicit diagnostics showing generated/normalized manifest
• Security model for script execution (sandbox/capability restrictions)

Why this matters

• Reduces dependence on external wrappers for core build/dependency logic
• Improves ergonomics for large and polyglot repos
• Enables reusable and maintainable build logic at the manifest layer
• Brings Cargo closer to modern scriptable build systems without abandoning reproducibility

Related issues / context

I know there are related constraints discussed in:

• Allow build scripts to add dependencies to the library being built #1417
• Support depending on generated crates #2570
• Generating entire crates during build.rs #8709
• support for env cfg dependencies #13150

This proposal is broader: a first-class programmable manifest model, not runtime mutation of the dependency graph from build.rs.

Proposed Solution

No response

Notes

No response

[epage]

For advanced workflows, users often want to express build/dependency logic programmatically:

• conditional dependency declarations
• environment/profile-aware dependency sets
• reusable logic/functions for dependency groups
• computed manifest fragments
• richer multi-target orchestration in one place

These are means to an end. The underlying problems being solved are important as they drive the conversation around requirements and solution evaluation criteria.

Keep in mind there are trade offs with being programcatic including

• can't edit with tools like cargo add
• harder to lint
• design effort for fast, deterministic building, especially when it comes to our stability guarantees

My operating assumption when exploring some of these problems is to have plumbing commands with a cross-language build orchestrator that is outside of our stability guarantees.