feat(blog): Share my vision for Cargo by epage · Pull Request #30 · epage/epage.github.io

epage · 2026-07-24T21:32:31Z

Tasks:

Draft of the problems areas section
Draft of the roadmap section
Edit for flow, grammar, spelling, links

weihanglo · 2026-07-24T22:48:52Z

+
+<a id="plumbing-commands"></a>
+
+#### Plumbing commands


Plumbing commands are great, though OTOH I personally still like to see a more modularized cargo libs, especially for Cargo configurations part. They seems to be two different development directions. Not sure if they conflict.

To clarify, breaking more crate out from the main libcargo.

I think the refactors from plumbing commands will better enable splitting Cargo into libraries but I think the general problems remain

complexity of abstracting away CLI assumptions

further design constraints librification will enforce on us

for the general case, plumbing commands should be the preferred route because you aren't locked into a specific toolchain version (e.g. if a project is using a new stable feature but their third-party tool uses cargo-the-library which thinkgs its unstable)

weihanglo · 2026-07-24T22:56:47Z

+If we added support for `cargo fix`,
+then an agent can delegate to that, saving itself from calculating how to do the work to address lints.
+
+One area I'm curious about in particular is what the role of [test coverage](#test-coverage) would have on Agents.


Not sure if you have thoughts on

Formal verification or model checking.

Fuzzing

More and more companies expand their test infra to those for AI-first workflows, though those may beyond Cargo's reach.

celinval

Thanks for putting this together. It's very enlightening.

celinval · 2026-07-25T19:51:59Z

+#### Adaptability
+
+Cargo is [intended to be opinionated](https://doc.crates.io/contrib/design.html)
+but between that and backwards compatibility,


How do you feel about eventual breaking changes to cargo, at least the CLI, for providing better functionalities? I think the LTS toolchain discussion fits in this a bit.

I totally understand the stability from the point of view that "Cargo strives to remain backwards compatible with projects created in previous versions.", i.e.: Cargo being able to virtually compile any crate that was ever published in crates.io.

I don't quite understand why cargo CLI cannot have breaking changes though. Does cargo need to strive to work with old CI and old scripts? Or is the concern here that build.rs scripts may invoke Cargo, hence, changing cargo would potentially break old crates?

We need to expand some more on our compatibility surface.

I see CLI flags and json output as part of an API that is meant for integration and therefore has similar compatibility constraints as other API surfaces that ship together.

Is there an area of concern where you feel the CLI is holding things back?

I wrote up some notes on compatibility at #t-cargo > Aggregating additional cargo design principles and decisions @ 💬

celinval · 2026-07-25T19:55:06Z

+
+In git, they divide operations into [plumbing and porcelain](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain).
+Cargo is almost all porcelain commands with very limited programmatic use.
+Adding plumbing commands and extending the programmatic output of the porcelain commands would go a long way to enabling people to adapt Cargo to meet their needs.


Do you think it's time for Cargo to embrace its role as a build system, or do you mostly see Cargo as an advanced package manager that has some build capabilities that needs better extension points for integration with more advanced build systems?

I.e.: Is the first line of the cargo book [1] precise?

Cargo is the Rust package manager.

I just noticed that the Rust programming language book uses a different language[2] 😀:

Cargo is Rust’s build system and package manager.

I think it depends on what you mean by those terms.

Currently, Cargo is an opinionated Rust build system with some escape hatches for practicality purposes (build scripts). It is not a general purpose build system. Personally, I worry the implications of Cargo becoming a general purpose build system but would like to better explore improved integration with general purpose build systems.

That makes sense. The reason I asked the original question is that today, Cargo.toml and the build.rs contract shape what a Rust package is, and they're tightly coupled to how Cargo builds things. This means more scalable, general-purpose build systems like Nix, Bazel, and Buck2 have to maintain translation layers and patch build.rs scripts because there are assumptions that are deeply Cargo-specific, like the growing set of CARGO_* env vars, absolute paths, and cargo: directives.

This leaves me wondering: should the package manifest and build interface become more decoupled from Cargo's build semantics so other systems can consume them more naturally, or should Cargo itself scale up to offer hermetic builds, remote caching, better sandboxing, and the other things that push people toward those systems? I'd love to see the vision touch on this — or if there's a third path I'm not seeing!

I would love to scale up Cargo with some caveats

I'm referring to at least performance but not general purpose build system capabilities

We likely won't get to "google scale" but there are still a lot of people in between that would benefit

A focus on user problems and not features (e.g. "sandboxing" means a lot of things to a lot of different people, what problem are we solving?)

We need to do so in a way that recognizes that not everyone will want or need this (e.g. linking against system libraries which is not hermetic)

That doesn't cover everything and it would be good to identify where we can improve with providing support to build systems. I have wondered about crate for parsing build script directives. Unsure what else could be worthwhile for bridging these gaps.

Sounds good. Thanks for answering these questions. So scalable build system for Rust with better integration points for other build systems, is that right?

epage · 2026-07-27T21:23:17Z

+Maybe the OS can help with enforcement to create highlight these audit points.
+Cargo should support a wide variety of OSs and they have different capabilities which may change with time,
+likely making this be best-effort.
+We will need to provide some way for build scripts and proc-macros to specify the resources they wish to access.
+Maybe we could make this also work for tests and `cargo run` but it wouldn't help with deploying your production binary.
+
+Maybe we go all the way to a wasm sandbox.
+This is trivial for pure proc-macros though other ideas mentioned here will help.
+The big challenge is supporting what is needed by impure proc-macros as well as build scripts.
+Like with using OS enforcement,
+we will need a way to specify what resources can be accessed.
+Wasm sandboxing can likely lead to slower builds and not just because of having to run a wasm interpreter.
+Cargo goes out of its way to try to allow proc-macros and build scripts to reuse intermediate build artifacts with a users application.
+When we've previously benchmarked diverging these builds more for "build performance",
+the results ended up being a wash because of the extra builds that happen.
+This is also limited in what it helps; 
+it would not extend to your tests, `cargo run`, or your production binary.


@weihanglo do you have any feedback from your sandboxing experiments?

When we've previously benchmarked diverging these builds more for "build performance",

I forgot. What was it? Should we link to those prior efforts?

And also we might want to look at from the angle of deterministic builds, which may help build cache reuse, though that alone could be a separate topic.

Generally looks good!

I always have a hard time looking up those various performance changes.

The other ideas also help with deterministic builds.

konsti-openai · 2026-07-28T19:30:36Z

+The output is much richer, allowing for better errors.
+
+PubGrub has been proven out by Astral with uv,
+including the ease of making changes like [changing how prerelease works](https://github.com/astral-sh/uv/releases/tag/0.12.0).


From my experience, pubgrub is great layer to build complex features with relative ease on top.

epage · 2026-07-30T16:51:24Z

Done with the first draft

celinval · 2026-07-31T05:30:15Z

+- Awareness of the `deprecated` feature
+- Discovering of the migration guide
+- The migrations are still manual
+- `unstable-vX` features can have surprising effects and need more guard rails to scale up their use


I thought there were plans to stabilize#[unstable] attribute for regular crates [ref]. Do you know what happened to that?

No idea but it was discussed yet again at the all hands, see https://github.com/epage/epage.github.io/blob/cargo/blog/blog/cargo-vision.md#api-lifecycle

celinval · 2026-07-31T05:54:21Z

+Maybe Cargo can use OS features to restrict build script and proc-macros access as a way to highlight these audit points.
+Cargo should support a wide variety of OSs and they have different capabilities which may change with time,
+likely making enforcement be best-effort.
+We will need to provide some way for build scripts and proc-macros to specify the resources they wish to access.


Yes, please! I get that this can be painful for crate developers to maintain, but hopefully we can add tooling to help them detect things they are missing, and also provide a reasonable default for things they can access.

Sound test caching would also need something along those lines.

Eh2406 reviewed Jul 24, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

epage force-pushed the cargo branch from a1c46e1 to 3d15dc6 Compare July 24, 2026 21:40

Eh2406 reviewed Jul 24, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

epage force-pushed the cargo branch from 3d15dc6 to c871b58 Compare July 24, 2026 21:45

weihanglo reviewed Jul 24, 2026

View reviewed changes

epage commented Jul 25, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

epage commented Jul 25, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

epage commented Jul 25, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

Comment thread blog/blog/cargo-vision.md Outdated

Comment thread blog/blog/cargo-vision.md Outdated

Comment thread blog/blog/cargo-vision.md Outdated

arlosi reviewed Jul 25, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md Outdated

Comment thread blog/blog/cargo-vision.md Outdated

celinval reviewed Jul 25, 2026

View reviewed changes

epage force-pushed the cargo branch 3 times, most recently from 656a6cd to eb40fca Compare July 27, 2026 21:22

epage commented Jul 27, 2026

View reviewed changes

epage force-pushed the cargo branch 3 times, most recently from 0a22f9f to 0941893 Compare July 28, 2026 19:23

epage commented Jul 28, 2026

View reviewed changes

Comment thread blog/blog/cargo-vision.md

konsti-openai reviewed Jul 28, 2026

View reviewed changes

epage force-pushed the cargo branch 3 times, most recently from 9fb6df4 to 6bbbe78 Compare July 30, 2026 16:50

epage marked this pull request as ready for review July 30, 2026 16:51

epage force-pushed the cargo branch from 6bbbe78 to ab7afc7 Compare July 30, 2026 21:40

celinval reviewed Jul 31, 2026

View reviewed changes

epage force-pushed the cargo branch from ab7afc7 to 7fc1608 Compare July 31, 2026 14:48

feat(blog): Share my vision for Cargo

83a3219

epage force-pushed the cargo branch 2 times, most recently from 194860f to 83a3219 Compare August 5, 2026 17:52

epage merged commit 995cf75 into source Aug 5, 2026

epage deleted the cargo branch August 5, 2026 17:53

Conversation

epage commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

celinval left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage commented Jul 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

epage commented Jul 24, 2026 •

edited

Loading