Cargo team meeting notes 2026-02-03

--- robots: noindex, nofollow tags: meetings --- # 2026-02-03 Out: Dongpo Attendees: Ross, Eric Huss, Jacob (Eh2406), Arlo, Ed Page, Tomas Sedovic, Nurzhan Saken, Scott, Weihang ## Nurzhan Saken, our new Program manager joined us! He'll be joining the meetings this week to get to know y'all. I'll take the minutes this week and Nurzhan will do it the next one. After a few weeks, we'll likely alternate the calls. So you can get familiar with both of our faces, get to know us and know to reach out to us. And so we both remain plugged into the Project. ## Project goals 2026 First look at 2026 goals post: https://blog.rust-lang.org/inside-rust/2026/02/03/first-look-at-2026-project-goals/ Please take a look, think about asks on your team. It has some examples for the sizes that team asks can be. ## FCP Reminders - build-std: always -- https://github.com/rust-lang/rfcs/pull/3874#issuecomment-3715844925 - build-std: explicit dependencies -- https://github.com/rust-lang/rfcs/pull/3875#issuecomment-3715845871 - cargo script -- https://github.com/rust-lang/cargo/pull/16569#issuecomment-3824367099 ## 2026 goal review https://rust-lang.github.io/rust-project-goals/2026/goals.html#cargo-team - Stabilize public/private dependencies - Ed: This is asking for help from the compiler people to work otu the last kinks of the lint - eric: Support levels: how are they determine - Tomas: the submitter proposes, the goals team review this and suggest, after that the team looking at it should be able to suggest/adjust - Josh: The goal template has some detail explanation for goal levels - Tomas: also - Eric: I don't want get deeply into it yet, but e.g. here the compiler has a small and it seems more - Ed: It wasn't clear to me whether we're asking the compiler - Ed: Should the work it include someone actually doing it? - Josh: If you don't have someone already lined up you should list the ask as larger - Josh: Are we confident in the semantics of it and just expect implementation? Or non-trivial refinement of the semantics? - Ed: The remaining thing is working out the transition plans - Josh: Okay,o in that case it seems reasonable to do as a goal - Eric: I had questions on semantics for the transitive dependencies - Ed: On the semantic,s if you say something's a public dependency then all of your dependencies are public as well - Weihang: We don't have to add it to the registry index right? - Ed: It's already in the index - Josh: Is there a plan to say "this is my dependency but I'm opting out of its dependencies being my public dependencies" because you're only exporting a subset of its API? - Ed: Right now, now. It could be complicated. Part of the idea is: you're defining a set, .. - Josh: "it could be complicated" is a good enough answer for not doing it right away - Arlo: What's the goal here? Details? Whether it's a good goal in the first place? - Eric: I'm less worried about the details. It's mainly about awareness -- these are the proposed goals. Is there a follow-up we need to do? Do we even consider this as a good goal? Higher level questions. - Implement Open Rust Namespace Support - Eric: Similarly blocked on compiler work - Ed: Two compiler people had some amounts of work on it, I'm not sure what's blocknig them - Eric: Are they still working on it? - Ed: I'm ont sure. Eric Holk is steppind down but his colleague Alexei?? is going to work on it - Arlo: Different uses - Ed: It's stated that it's not meant for organizational usecases. Our framing can help. How we develop it and expose it can change it. I talked to rustdoc folks -- how do we expose things to make it feel like they're part of one namespace. The same API - Arlo: We need to make sure that the messaging is clear on this - Ed: I agree. Other Rust teams are not helping. - Finish the libtest json output experiment - Ed: Once I'm wrapped up with what I'm doing now I'll start working on this again - Eric: What's the ask on the rest of us? - Ed: Eventually I'll prototype `cargo test` communiccate with libtest json. I migtht need reviews for that. - Arlo: That seems great. Plenty people use RUSTC_BOOTSTRAP to get this - Weihang: I pushed this, a lot of companies want this. I can be the SME to review if you want - Continue resolving cargo-semver-checks blockers for merging into cargo - Eric: Predrag keeps moving on, but I'm still a little concerned about the actual feasibility of getting this into cargo this year. - Ed: I've similar concerns - Weihang: Does Predrag still plan making it into Cargo? - Ed: Distributed with rustup. Unclear whether it's built-in directly in Cargo or shipped as a separate binary. But the question is: is this good enough for distributing with rustup? There's a lot of lints that would have a big impact that aren't sensible to implement. - Ed: Can he do type checking or do a workaround for that? - Arlo: What's the stability guarantee - Ed: In terms of command itself, once it's no longer a preview rustup component it's stuck up on compatibility guarantees - Ed: Another concern: the CLI - Ed: But I'm for supporting him continuing to explore the problems and come up with proposals. Happy to liaison with him on that - Eric: Makes sense. I'd love to see it go forward but there's a lot of concerns here - Josh: Love to see it as well. This came up in Lang and in Libs API -- there were lints going out of their way checking whether something's pub or not, and it'd be better to lint the diff. And that's exactly the sort of check that would fit here. Better that than ignoring a lint on all public API by default. - Weihang: The other endgoal is: what can we help Predrag with? A concern is things where they reimplement something. E.g. part of cargo config probing. It's unfortunate we don't provide config probing for other people. Is that something we could help with? - Eric: I was thinking how we can work with Predrag more to make sure we understand each other and be clear on what we need to move forward. See if we can sync up a bit more. - Weihang: Right now we do the morale support but we don't do more than thant - Ed: That's also partly on him -- ask us what he needs support with - Weihang: There was json output for custom targets when you allow an unknown target, it'll always be allowed or something IIRC. And that broke the assumption of cargo-semver-check. IT's a bug in cargo and rustc. Thats' the sort of thing we can help with. We could be more proactive in helping with things like that - Prototype a new set of Cargo “plumbing” commands - Ed: This is in a "help wanted" state. A GSoC person started but there's more to do. The next section is refactor cargo to support runing its logic as plumbing commands. Assume not everything is loaded from file immediately - Interactive cargo-tree: TUI for Cargo’s dependency graph visualization - Eric: What's the context on this? - Ed: I'm acting as liaison on this. Goes back to conversations about TUI for some things and the idea was that cargo-tree might be a good step to try with a TUI. What it's like to get that integrating and getting upstreamed in cargo - Arlo: Can it be started as a plugin? - Ed: That's what it is now - Josh: This grew out of a conversation with Orhun? with several cargo folks at conferences (one in China, and possibly prior to that at the Rust All Hands?) - Ed: There's also a conversation with Tim at all hands where you could dig down into this - Arlo: Could this tie into the plumbing goal. Have a plumbing command that could give you the information that would let you build upon this - Ed: Having cargo-tree produce something you could build on top of? - Arlo: Having a plumbing command that would give you a machine-readable output for cargo-tree - Ed: That's a bit of a mistormer having a plumbing command. The way way the plumbing commands are broken down today, you'd get a feature resolver plumbing command that you could build visuoalization on top of. - Stabilize cargo-script - Ed: I didn't include any future possibilities like workspace support so this is just wrapping it up - Crate Slicing for Faster Fresh Builds - Eric: First time I've heard about this - Ed: They're creating a 3rd-party tool that lets you create a subslice of your dependency graph that only includes the things you need to build. But this is just the prototype to run the benchmarks and running the benchmarks to us - Ed: Unclear whether this needs anything from us, they can just doing - Ed: It seems like a great investigation, but then it's more about the compiler - Josh: I woludn't expect the final result to massive change Cargo but there may be some integration to understand the pre-slice crates. But as presented (we want to experiment) and the output is presenting the benchmarks, that seems like areasonable scope for the goal - Ed: The ask for Cargo is about discussing the integration with cargo - Ed: Think of hint mostly-unused but doing a pre-analysis step to do that. E.g. you only need 5 parts of tokio and stripping everything else. - Arlo: They do mention registry proxies serving pre-sliced crates, build.rs slicing etc. - Josh: I don't know they're necessarily asking for a substantial amount of work from us. Here I think they're mostly asking to have a conversation with a team. - Arlo: This "medium" seems signcantly less work to me than some vibes - Ed: It indicases to me that he wants to have some deep dive levels of conversation - Ed: I'll reach out to the author and have them update the project goal - Eric: Tomas can you stay on top of this? - Tomas: absolutely (TODO) - Stabilize Cargo SBOM precursor - Arlo: I was surprised someone picked it up. I'm not sure whether the "medium" ask makes sense. A lot of it is done. What remains is getting this integrating it all the tools, proving that it's useful and stabilize it - Ed: The RFC is not done - Arlo: Yes, but I don't think it's worth doing that until enough people are stabilizing it - Ed: sbom precursor files - Arlo: I think it's a stabilization blocker - Arlo: Context: I started working on this because my company asked them to integrate with their SBOM tooling. I'm not going to work on it myself - Ed: Do we need a champion - Weihang: My employer is still interested in it, so maybe? - Arlo: If someone else is working on it, I'm happy to participate and review - Eric: What are the next steps for the goal? - Tomas: Knowing about it, thinking about it is a good start. Will need a champion. We'll reach out for that. If there is no champion, or not what we want to see, we won't accept the goal. The goals team will facilitate that. - Arlo: If I read the project goal proposal, a lot of it seems very little asks on cargo other than the RFC. The rest can be through the normal issues etc. - build-std - Eric: Adam's already working on things now. There may be some changes in Cargo we can do before any major steps are taken. There are some small movements happening right now. - Josh: I'm looking at the Compiler, Libs and Cartes.io and I wonder whether it's realistic that all these asks are small? - Josh: The work items are: run a meeting, advance the RFC implement. But not actually say stabilize. But if they want to include even a partila stabilization, that would be potentially a medium ask for libs - Eric: It seems this has been copied over - Josh: Makes sense. I'll start a thread on zulip channel. - Eric: Team asks, notes on stabilization etc. would be great if they had more details Ross: I'll try to open a goal for ??. Josh: a goal that's open after the period needs a pre-approval and a champion. ## cargo script https://github.com/rust-lang/cargo/pull/16569 epage: risks of most concern: > If people share their build-dir across projects, then multiple scripts will point to the same Cargo.lock, fighting over what is locked in it > Not allowing local config for scripts could become a problem as we get into workspace support as people would expect their repo's config to be respected when it won't be Config change - https://github.com/rust-lang/cargo/pull/14749 - https://github.com/rust-lang/cargo/issues/12207#issuecomment-2358818671 Scott: This isn't necessarily a footgun, but if I'm running a cargo script, I'd want one lockfile for it. If you're running it with all the build-dirs together, you're not getting one of the benefits of using a cargo script that would have a lockfile. It's something we'll want to document. Ed: If a user wants to share their build-dir, there won't be a way to do that except with cargo-scripts Ed: The other issue: recheck in on our previous decision on how to load config (a) load from environment (b) load from cargo home like cargo-install (c) load based off the cargo scripts location Ed: I implemented (c) but there's security concerns running scripts out of downloads directory. But it sounds like you have to be in a contrived situation. But people wanting to put them in their repos, ??. It's a bit contrived because you'd have to dowload a zip that would generate a `cargo/config.toml` file. Eric: We'll talk about that more.