Cargo team meeting notes

--- robots: noindex, nofollow tags: meetings --- # Cargo team meeting notes https://meet.jit.si/CargoTeamMeeting Label issues or PRs with [**I-nominated-to-discuss**](https://github.com/rust-lang/cargo/labels/I-nominated-to-discuss) to add them to the agenda. [**FCP/Nominated/RFC Status Overview**](https://github.com/orgs/rust-lang/projects/47) ## 2025-10-28 - Scott: Use test name for test directory in cargo's testsuite - https://github.com/rust-lang/cargo/pull/16121 - Josh: Next steps for stabilization of hints.mostly-unused. Are we ready to stabilize if rustc stabilizes the underlying options? - https://github.com/rust-lang/cargo/issues/15644 - (backlog) https://github.com/rust-lang/cargo/issues/5866 - Cargo metadata doesn't include actual filename of binary targets - (backlog) https://github.com/rust-lang/cargo/issues/5881 - Allow setting linker args that only apply to bin or lib targets ## 2025-10-21 - epage: stabilization path for new build-dir layout: https://github.com/rust-lang/cargo/issues/15010 - While unstable, there are reasonable tools relying on the layout due to missing cargo features (coverage, gc) - Without this, we might end up requiring stabilizing the new build dir layout, granular locking, and target dir GC all at the same time - We'd like to reduce some of the nesting (`profile/platform`) because it mostly exists for locking purposes which might be aided by https://github.com/rust-lang/cargo/issues/4282 - For granular locking, mutable build units are an issue. What if we made them all immutable? We'd need to move the fingerprint into the directory name (and ensure the directory name doesn't end up in the binary) and aggressively GC previous iterations of these "mutable" immutable build units - We could stabilize build-dir, but it would require stabilizing locking and GC - What are pepole's changes of stabilizing portions of it and be able to make some layout changes later - How do we feel about having a couple of transition points for build-dir layout changes - Jacob: Have we came up with ways to make it easier on making the first transition easier? - epage: All this is unstable for now - Scott: Have a crate that could grab the builder that woudl update every time cargo makes a change? And later on pull that crate to cargo - epage: I'd never want to make it official because it's not stabilized - Scott: but that would still be useful to let people deal with these - epage: One concern is, how will people use it, how to even figure out how to even build this crate - Jacob: do we even have a list of usecases for what people are doing here? - epage: Some of it is for cleanup specific data, some of it is generating something with build script in out-dir and they want to access it - https://github.com/rust-lang/cargo/issues/13663 - https://github.com/taiki-e/cargo-llvm-cov/pull/452 - Scott: we could do a best-effort thing that people can look at and adjust to their needs - Josh: Would part of this transition strategy be some public communication: "we're making this change, here's the timeline, here are some examples of cases where they're accessing a build directory assuming it's the target directory" - epage: We've not started a communication plan yet. - epage: Part of the motivation was to more clearly communicate what's specified and what's not specified. Part of that communication would be: "if you can change the location of build-dir and it breaks you, you're relying on internals of cargo" - Josh: Would it make sense to do something like a crater run? To understand how widespread a disruption would the change - epage: Even if build script relies on it, it's something else reading it. I wouldn't expect there being a lot of breakage in crater - Josh: Right. Though if there's any crate in the ecosystem depending on this, that might show up - epage: most of this is likely things like man pages, shell completions etc. - Josh: What I was thinking about is: you're compiling a C library, doing so generates a header file and another library would read its headers. - epage: I'm not familiar with this, I'd assume all that to be done in one crate - Josh: Some people have multiple C libraries and then a top-level C library fetches all the headers and includes it in its build. Any case where a `*-sys` depends on a `*-sys`. - epage: Only doing a Crater run on sys crates? - Josh: Yes, and that should be a small-ish crater run. And it would be a good smoke case. - Eric: any reason not to do a full crater run? - Josh: I'm all for it, but it takes longer and it's harder to triage to handle spurious failures. - epage: Do you know of crates that do this kind of layering, Josh? - Josh: Any -sys crate that depends on a -sys crate. - epage: In terms of the original question: what are people's thoughts on our tolerance on transitions? - Eric: What do you mean by "transition 1" etc. - epage: Trying to do one perfect transition started to compound with different features. Can we do multiple e.g.: build-dir layout, then GC, then granular locking, etc. - Josh: I'm all for decoupling as much as we reasonably can - epage: re GC: we can make the locking much easier if every build unit's output is immutable because we can treat everything as append only and keep adding things. But some build unit output is mutable because of pipelined builds. So we thought about simplifying by removing our reliance on fingerprint completely and putting all information into the directory name the rlib goes into. Every time you have a source change you get a new output directory. The size will go up so we have to aggresively GC them. So that's why we thought you may want to have GC before granular locking. But granular locking may cause us to change the build-dir layout - Josh: What are the various variables that will be used in the new build-dir model? - epage: There are no new variables, we changed that out-dir is now inside build-dir rather than pointing to the stable output directory. - epage: There's then an issue for providing a way of exposing artifacts generated from the build script. We're against exposing it because it could cause issues with our locking. So instead, we're thinking of providing a new build-dir directive that would specify the artifacts and these would then be added to the right place. - Weihang: We have the `DEP_<name>_<key>` variable. People can abuse that. I think any downstream package will consume that. - epage: That's intended to be able to communicate things to your dependents. Our concern is the other direction: to communicate things to your dependencies outside of features etc. - epage: Is there any concern with us to come up with a stabilization plan for the new build-dir layout? - Jacob: Agreed. Let's make the first one as orthogonal and small as we can and then we'll see how painful that will be and plan the transitions after that. - epage: Yeah, depending on the how that transition goes we can see. - Eric: The idea is that this wouldn't be opt-in, corect? - epage: Yes. We could treat it like a registry where there's an env variable that would be opt into the new layout, then switch to opt out of it, but I'd rather not go there. - Eric: And the other part is to provide ways for people to adapt their tooling. - epage: I wasn't planning on providing a way for people to access these things. Without being deeply integrated for the tools, I wouldn't even know what to provide. - Eric: cargo-emit is depending on this. - epage: I need to know what they're actually looking for. They would have to look at the hashes. - Eric: There's no hash, they just grab the latest one. - epage: I see, there is a fixed directory with a fixed filename and now we're switching away from that. We need to talk to those authors and see what they are using and how to help them. - Weihang: on the other side, there's a lot of tools outside of Cargo ecosystem that all have their own build scripts and we should contact the big build system maintainers because they're probably misusing the private layout. - Eric: I can try to bring up a list of tools that I know would have a problem with this. I think we should not take this lightly, breaking a part of the ecosystem. - epage: We need to be clear that this is unspecified and not have it be a configuration option. Having to support it sounds unmaintainable to me. - epage: If we need to maintain this for them, we should say all this layout stuff is stable instead. - Josh: I'm all for maintaining a lack of configuration. Smoke out anything that depends on this and try to fix it. One thing we could do: could we apply these patches to nightly, then revert before getting to beta. So anyone doing builds with nightly, they'd observe the breakage and we can see people affected. That would buy us more time for being able to fix whatever comes up. - epage: I think that's another viable strategy to consider for the migration plan. The other is having an opt-in/opt-out env variable. We'll have to talk about that and figure out what the plan is. - epage: I'm talking about a transition period: stabilize, but have an variable that would be basically an unstable flag. And then remove that variable. - epage: Sounds like at this point is to come up with the transition plan and look at some of the crates that Eric is aware of. See if they rely on target-dir and create an issue for them so they know what's coming. - weihang: insta-stabilize support array of any types in Cargo config - Like `[[include]]`, `[[patch]]` - https://github.com/rust-lang/cargo/issues/16111 - It is a feature that has no stable use case - We only support arrays of strings right now - I've added a PR that supports arrays of anything (including arrays of tables) - That would let us to have optional includes, array of patch file tables - It would become insta-stable -- do we want to do that or should insta-stabilization be bound to an actual usecase? - The danger is if we instastabilize it now, when the time for using it comes, we may run into issues of not having considered the design fully - epage: In general I'm for "let's do things when we need them". My concerns here around merging roles etc. We had discussions on the issues for potential usecases for non-string arrays. But if we already have arrays of strings, we have most merging figured out other than for the arrays of tables. I'm not sure how that behaviour would change with us adding more usecases. - Weihang: Yes, if we add different merging strategies, things would get complicated quickly - Eric: Weihang are you specifically working on config include changes? - Weihang: Yes, I'd like to resolve the config include syntax blocker - Eric: Are there any current concerns with landing this now? Other than the uncertainty about the future usecases? - Weihang: That is the major concern. But if there's no use case right now, we could revert it, but we may overlook that when we add a new usecase that uses the any type. - Eric: Does anyone have concerns? - epage: It's in FCP, people can bring concerns there. But we should have a sync discussion. - Scott: No concerns other than what was brought up. - Weihang: my concern is if you set an table of an array item. But most people wouldn't do that. - Eric: If there are no questions now, there's the FCP and people can follow-up on there - Scott: Add `typos` CI job - https://github.com/rust-lang/cargo/pull/16122 - There have been PRs open with typos in changes so I added a configuration and put up a PR - it's a non-blocking check - The config's based on what Rust recently added in their spellcheck - epage: if we do it I'd rather make it a blocking job. It's used in the Rust project etc., there's no use to test the waters here. Having it be non-blocking it's going to be easy to mark things as automerge and not having these handling. That would necessitate a separate PR and having our CI red in the meantime. - Josh: Would it make sense to have a blocking CI job, but have it pin a particularl version of typos? - Scott: That's what we currently do here and that's what rust-lang/rust does too - epage: It would be pretty trivial to add a Rennovate bot and have it update - Scott: The only caveat is that we can't run this locally for now - Josh: how hard would it be to run typos as part of `cargo test`? - Scott: That's how they do it - epage: It's a bit expensive to build typos - Scott: But that should be a one-time only. We would update it every two months or something. - epage: If it's using our dependency management, our monthly bot could cause all the typos be rebuilt. - Scott: yeah unless we specify it not to do that - Eric: Is there no interactive mode there? - epage: Not yet. There's a PR that it stalled. What would you like an interactive mode for? - Eric: Two parts: one is fixing the actual mistakes. The other is handling false positives. That sounds challenging. - Scott: Cargo's typos.toml is sligthly more complicated. We tried the rust-lang/rust - Eric: I also don't want to have optional CI jobs - Weihang: It might cause beta backports difficult - epage: Typos are pinned in CI so that shouldn't cause an issue - Ross: I'd prefer running typos standalone if it means I cut down on compile time when building/testing cargo - Scott: Confirming: no one is against adding a typos job, it should be blocking - Josh: I'd love to be able to run jobs locally in the exact way the CI runs - epage: there's a pre-commit project that could run typos before committing code - Scott: that's if you can run precommit hooks (I use jj) - Eric: sounds like we're okay with moving forward, most of us would like having a required job, some figuring out of how to run it locally but we can leave that to Scott and Ed and figure out those details ## 2025-10-14 Out: Tomas Sedovic - build-std update - RFC may be posted next week or so. - epage: Wondering about splitting the first RFC, since it is in two parts, and there can be very different conversations about them. The dependency one could even be independent of build-std. - https://github.com/davidtwco/rfcs/pull/4#discussion_r2399746547 - josh: I'm of two minds. It may be more about just where the background goes; they are related parts to the same story. - josh: Do you think the dependency one should be written to be *independent* of build-std? - ed: I would put that on David if he would want to do that. - ed: Also, compiler people may not care about the crates.io one, which could be a lot of noise in that sense. - ed: Also wondering if the main rfc could be split into a stack (base architecture, compiler work, etc.). - eric: Will talk with them during our meeting this week. - https://github.com/rust-lang/cargo/issues/16023 - False positive "be sure to add .local/bin to your PATH" warning with relative install root - eric: Two parts here. One is the message is kind of wrong, the warning should indicate the absolute path. The other issue is that it is surprising that the relative path is relative to the current directory. - dongpo: May want to update the documentation. - weihang: Also confusing which config path resolve to which one. - config-include is cwd, others is parent directory. Some people have asked for some template solution since it is not clear. - josh: Should we add a new warning that you probably didn't want to use a relative path? - scott: What if someone actually does want that? Could be lint, but don't have a way to configure that for config. - josh: "Warning, this is installing relative to the current directory", could be viewed like a verbose "helpful" message, not really a nag. - josh: Or it could be "note", which could be less annoying. "Note: installing to /home/you/.local/bin, configured as .local relative to current working directory /home/you" - scott: Would agree a note would be better. - josh: Print it at the end. - scott: Could somehow allow the configuration to allow an inline table. - eric: build-dir has templates. - eric: Wondering if there is an appetite for adding more templating to config values. - ed: Would be cautious. It can be useful, but don't want to say use it everywhere. - josh: Would want to be deliberate with the reasons for it. - ed: Current-directory just feels broken. - josh: Would also be willing to change, with some kind of transition, but somebody's install script likely depends on this. - josh: Would be more ammenable to not supporting it from their home directory config, but allowing it in a project directory. - ed: It's still not good in a project directory, since if you change a directory it throws everything off. - ed: Could warn we plan to deprecate it in all cases, and see if anyone complains. - scott: Would be fine if it the timeline is long enough, with an option to opt-in to the old behavior. - ed: Would want to wait to see if anyone actually needs it. - weihang: Deprecation warning may not reach people using this feature, since those people are doing some weird build-system scripting, and it may not reach them. But also agree this is a bug and should probably fix it. - eric: If we were to deprecate, we would deprecate just the one that is relative to the cwd? - josh: Yes. - eric: What would it look like? Print a warning for now, and then later switch the behavior to be relative to the config file. - josh: To make it suppressible, and to work with older cargo, could print a message that says "because it doesn't have a slash, it will be relative to cwd, it is deprecated, will be fixed in a future version, if you want to suppress this warning and work with all versions of cargo, add a trailing slash (and here's the file where it is defined)". - josh: Will write a summary. - For the existing warning, we'd also like to fix it so that it prints an absolute path. - https://github.com/rust-lang/cargo/issues/16062 - Build script: Adding directive cargo::no-new-rust-code to speed up compilation - eric: Ed has a good summary. It seems like a lot of work to me, as there are a large number of big changes to support this. - weihang: Would like to wait for link-only/no-link to be more stable before working on this. - ed: Could be a chicken-and-egg thing. - weihang: It does have its own value, because rustc-driver dylib, something can be removed if it was supported. - josh: What I'm wanting, if build script is so independent, would it be possible for it to be a separate crate, and then we know how to pipeline separate crates. The build script would be completely independent package without a rust library. - ed: What about in parallel, refactor build script processing so it can handle streaming instructions? - eric: Sounds good to me. - josh: Would it be reasonable to ask them to prototype this, to see that as a component of a design? Or would that invite too much work up front? - ed: Any route is invasive enough to have some things settled before having a prototype. - josh: In some way this is adding more build script power, where we are wanting build scripts to more go away. - ed will write a response. We would accept changes to support streaming build script instructions. But beyond that, this would need more design work, and also wait for link-only/no-link to be better supported. ## 2025-10-07 - weihang: https://github.com/rust-lang/compiler-team/issues/915 - Just a heads-up. No need to rush into discussion right now. - https://github.com/rust-lang/cargo/issues/16062 - epage: When escaping the script's filename into a package name, we currently use the more strict `cargo new` rules. Should we use the validation rules instead? - https://github.com/rust-lang/cargo/blob/fbe6193f847770b0a5d4f014cafd31191ed02a6a/src/cargo/util/toml/embedded.rs#L61-L75 - maybe be looser on the bin.name, see also https://github.com/rust-lang/cargo/issues/12870#issuecomment-3290896177 - https://github.com/rust-lang/cargo/blob/fbe6193f847770b0a5d4f014cafd31191ed02a6a/src/cargo/ops/cargo_new.rs#L168 - https://github.com/rust-lang/cargo/blob/fbe6193f847770b0a5d4f014cafd31191ed02a6a/crates/cargo-util-schemas/src/restricted_names.rs - josh: `cargo new` is stricter than we want here. - ed: Should the windows check be dependent on running on windows? - josh: Those names are irrespective of an extension. - eric: On modern windows, most names are no longer reserved. - arlo: If the script is already starting as a filename, then whether or not it is reserved is already handled by the existence of the file. - weihang: Is it a breaking change to make it strict now, and relax it later? - ed: The sanitization adds characters, the name of the executable will change, and the JSON package name. - ed: `Running /Users/foo/.cargo/target/xx/yyyyyyy/debug/test-` - josh: If the artifact directory is split from the build directory, that would remove the restriction on `is_conflicting_artifact_name` - ed: Can probably allow keywords. - ed: Can probably allow `test`. - Conclusion: Only restriction would be unicode xid-start/xid-continue to make it "identifier" compatible. - epage: how to filter `cargo tree` for public dependencies - https://github.com/rust-lang/cargo/pull/15243#issuecomment-3363938629 - Currently, `cargo tree -Zunstable-options --depth public` - Alt: `cargo tree -Zunstable-options --edges public` - The only cross-cutting edge type we have right now is `no-proc-macros` which is already a bit of a special case - Would it make sense to users that this is a filter being applied to the other edge kinds, excluding `public=false` edges? - scott: yes `edges`! - josh: Is the interaction of `-e features` with other edges a precedent for this kind of thing? - ed: Would only do `public`, don't have a use case for `no-public`. - ed: Different views. With `depth` is a little more handwavy, but `edges` is more literal. - arlo: To get your own public, would it be `-e public --depth 1`? - ed: Could potentially remove it until there is a clearer design in place. - ed: Example of what I used this for: https://github.com/rust-lang/rust/issues/119428#issuecomment-2686384070 - ed: If we do `-e public`, then it would show your public + transitive public. - josh: Reasonable to have `-e public`, separately later resolve the recursive with special edge type. - eric: That sounds reasonable to me, too. - (backlog) https://github.com/rust-lang/cargo/issues/5579 - Tracking issue for build plan generation (--build-plan) - [Should build-plans be deleted?](https://github.com/rust-lang/cargo/issues/7614) - ed: Would be good to go through and look at the different use cases. - ex: Getting build script out-dir, we probably wouldn't want a stable way to do that. - Wonder if we could have a mode that logs the commands that run, and then have a way to print those out again. - josh: Use case of running cargo on one machine, and running rustc on a separate system. - ed: Wouldn't that just be a rustc proxy? - josh: That would have too much overhead, don't want to fork/exec on local system for each one. - ed: How to support that with cargo's execution system to be able to run commands like that without some intermediate proxy? - ed: Thinking about cargo plumbing to generate the unit graph, and then a separate command that runs it. - josh: build-plan isn't the ideal solution on either of those things. Probably not worth keeping it in its current form. - josh: If it isn't used in bazel et al, then it's probably ok to remove. - weihang: If remove, do we drop the entire idea, or just this flag? - josh: Dropping the flag, with the idea to consider a different design later. - josh: Does `--unit-graph` include build scripts? - yes, there is a separate unit for building and running. - ed: Could only stabilize unit graph that it goes from one step to the next, with limited ability to change it. - josh: Document stable split points incrementally. Initially the entire thing is opaque. And then, certain split points are allowed later. - ed: Planned the ability to trim down certain output that they want. - josh: Would like the ability to prune a branch, and tell cargo that here's the results of running that branch. - arlo: Do we need something in place before deleting build-plan? - josh: Does having this at all make it harder for adding new things. - Weihang: Definitely shouldn't add things to it. - arlo: Or maybe just let it sit around if it doesn't cause problems. - ed: cargo-plumbing is not at the point that people can use it today. Probably can't yet transition to it. - Deleting build-plan could direct help to replacement for build-plan. - josh: Could have a 3 month deprecation/removal. - arlo: It's been sort of in that state for a few years. - weihang: What is the cost of leaving it? - arlo: Could defer until it is a problem. - weihang: It could be broken, and then we don't want to fix it. - weihang: Users are probably in enterprise environments, may not be on GitHub. - arlo: Most users have probably been scared off. - josh: Does anyone want to advocate for keeping it indefinitely? - ed: Advocate for deleting it. FCP to provide a window of time for final warning/feedback. Wording about the alternative approaches to the use cases. - josh: Could do this at the beginning of a dev cycle with 6-12 weeks to come to terms with it. - Oct 24 is next branch date. - josh: FCP that we plan to remove it at the end of October. - ed will start the FCP. ## 2025-09-30 Out: weihang - FCP Reminder: [Add target="host" meaning the current host](https://github.com/rust-lang/cargo/issues/13051#issuecomment-3312988872) - Eric: Ed you had some concerns? - epage: My initial concern was with the host name which be confusing. Weihang renamed it to "host-tuple" to make it clearer what it means. - Josh: Can you clarify when you're talking about the ambiguity? What might we confuse this with? - epage: there's compilation host mode and the cross-compilation for the host tuple. Weihang clarified this to make sure this is a substitute to the host triple mode, not the cross compiler mode. - Jacob: maybe we need target=unset or target=none? - epage: I feel like "unset", "default" don't communicate what's happening no their own. - Josh: Are we still more or less thinking compatibility-wise long-term we want to move to there not being difference between cross-compiling to host and not-cross-compiling to host? - epage: is there a way for us to do it? - Josh: There are ways we can introduce the compatibility mechanism. The fundamental issues are the paths within the target directory. If somenoe's running target/release/my-binary-name and expecting it to work, for that we could just symlink target/release to target/host-tuple/release or similar. This could either be solved by a symlink or writing a binary to two separate place. - Josh: Someone did show how to do more compatible symlinks on windows recently. - Arlo: that's what rustup uses I believe - Arlo: I agree. - Josh: I'm not trying to say we should prioritize it higher. I'm observing there is a path to solution for that one which suggests `--target=hosts` until we solve the problem. - Arlo: host-tuple doesn't make it more confusing to me. - epage: If we stabilize the hosts table in the config, we need to clarify that the hosts table doesn't apply to the host tuple. Is this aligned enough with where we going? - Josh: Seems part of the problem is: the current situation where we don't apply target applies to host. And when we try to apply a different meaning to host causes confusion. It doesn't seem like we'll be able to successfully remove all confusion. The people originally proposing this wanted a short alias. - epage: The people asking for a short alias are asking: can I always put this in the config? The convenience factor is the variability factor. host-tuple also parallels rustc's `print-host-tuple`. At least for me it provides some separation for the `host` table. It makes it easier for us to have these conversations in the future. If we name the placeholder to `host`, it would be more confusing. There's always going to be some confusion for the cross compilation, but we'll add to it if we have two things named `host` that meen different things. - Eric: does this sound good to everybody? [...] Sounds like a direction we can move in. - FCP Reminder: [feat(publish): read token from stdin](https://github.com/rust-lang/cargo/pull/16001#issuecomment-3328769505) - Eric: I had a minoc concern: it was implicitly reading from STDIN and I wasn't comfortable about that. I was asking if we could make it explicit. - epage: What if we deprecated this and require login/logout? - Josh: Do we already support reading from stdin or are we adding it? - epage: We have it for login but not for publish. - Josh: When cargo publish invokes things like cargo test, it doesn't hand the STDIN of its own to the tests, right? I'd assume we either inherit STDIN or provide /dev/null. If we're passing the token, we shouldn't be passing it to other programs - Arlo: I agree, this is worrying. - Josh: I'm not considered about malice here, it's more about something stupid happening like a test trying to read stdin that gets printed as a test message. - epage: "protecting against Murphy not Machiavelli" - Arlo: you do make a good point about the environment variables. - Josh: Exactly, we might want to consider unsetting that specific environment variable. - epage: Probably the safest way is to deprecate without providing an alternative. That will let people provide feedback and see what the usecases there are. - Eric: The more you say it the more I'm getting comfortable with cargo login. We can also check in with Weihang. - Arlo: I think cargo login and environment variable are good. - epage: I appreciate the author's initiative. - Arlo: Can we redirect them to just the deprecation path? - Josh: Are you suggesting they may be willing to do the work getting this deprecate? - epage: They are willing to deprecate it. - Eric: That sounds like a good plan to me. If we need to course correct within the next day or so, we can. - [Goals](https://rust-lang.github.io/rust-project-goals/2025h2/index.html#cargo-team) check-up - Eric: any thougts on how the goals are going? - epage: I'll be prototyping cargo test using the json output libtest will do. I'm prioritizing cargo script. But I have a general design on the test output. If people have thoughts on test UX and test APIs and functionality, talk to me. - Eric: The other one was `cargo-semver-checks`. It seems it'll be a large jump from here to getting it to Cargo. - epage: I've laid out at least a couple of basics: checking semver related things in `Cargo.toml`. But then there will be conversations around UX. I've not seen Predrag (the point of contac) about this much. He has to basically re-implement the name resolution. - Eric: It's a concerning project due to the scope. Predrag has been doing great stuff, but I also get the sense he's constantly stressed about funding. That's a difficult combination. - epage: That also worries me. If it's a one-man thing not built like Clippy, how will we bring this into the project. I'm not sure where to put this to help people know when they are making changes. E.g. marker traits being created without your knowledge that you only find out about when people get broken. - Eric: the other big issue that concerns me is the instability of the json output. - epage: Once it ships with the project, it should become more stable. - epage: I think Predrag is using the rustc version output. But tracking nightly and stable and beta and cargo could become diffucilt. - Eric: If they change the format, it will fail. - Jacob: I think cargo-semver-check doesn't support just the latest. - epage: It supports three latest stable. - Jacob: If it only supported one, figuring out how to break this deadlock would be problematic. But if it's supporting more, we can fix this. - epage: I think it's mainly an issue of friction for contributors that would go away if we had subtrees. - epage: https://github.com/rust-lang/cargo/issues/12870#issuecomment-3291110968 `script.rs --help` reports `script.exe` instead of `script.rs` - If we can't guarantee support for mucking with things to report `scrpt.rs` for all platforms, are we ok with being inconsistent or changing this over time? - epage: There are hacks we could do on our side because we have `CARGO_MANIFEST_PATH`. But this could get complicated. So people requested if cargo could override whether its current exe argv[0]. But that's not something every platform support. - Josh: Not all platforms support this. But also not all platforms supoprt shebangs at all. I suspect the platforms where people expect `argv[0]` to work are also the platforms that support shebangs. - epage: I think it's more that if you use a library like clap and you use `--help`, you'll see `foo.exe` in the usage line. So e.g. instead of `test.rs` you'd see `test-.exe`. - Josh: I'm suggesting we do this on the platforms we can and then have people bring up platforms where this doesn't work to see how to provide it. - Jacob: Two things here: what is the executable. And what is the script people thought they were running. Do I understand the problem directly? - epage: I think so. - Jacob: For context, what does Python/Ruby/other tools do? - epage: Python and Ruby are probably different because they're interpreted. More applicable would be things like dlang, etc. do. But those are less common. I think Python and Ruby do have argv[0] be the name of the program. - Arlo: The most common usecase for this is for tools like clap that say "I need to have the name of the command line". - epage: There's a separate conversation about re-executing. The main request is a UX thing. - Arlo: I'm talking about printing something the user that conceivable paste. - Josh: I was just digging into the possible answer to this and as farr as I can tell, people say you can call CreateProcess and pass in an lpCommandLine string and that's interpreted as `argv[0]`. - Arlo: Yeah, you're supposed to pass the program's name there but you can pass anything else. - Josh: We should ask a Windows expert. - epage: Do we want the argv[0] represent what the user would want to run or what the user would re-do programatically? - Arlo: or do we want to represent a third thing? - epage: For clap, how do I decide whether use the manifest path or the executable name? - epage: If you're not using cargo-script, it's supposed to represent the user file name (the name of the binary). It's meant to be adaptive. To do that it uses argv[0]. - Josh: Obviously we can pass what we want via a nonstandard environment variable. - Eric: I'm saying the environment variable already exist. - epage: But it's not clear when to use the environment variable vs. argv[0]. - Eric: Are there any other similar tools that aren not interpreter like Python and Ruby? - Eric: I think Josh earlier said just do a best-effort. - epage: If we start with a best-effort argv[0], it's easier for us to revert that and do the executable path if we decide to go the other way. - Arlo: I'm leaning towards it argv[0] being the rs path - epage: If we're mostly using it for CLI help, current_exe is not what we need to worry about. - Jacob: it makes sense for all platforms to have a way for getting both pieces of information. We should make sure they're both available and documented. - Eric: I feel if it's documented, that's probably good enough for most people. - epage: I'm leaning towards argv[0] being the script and current_exe being the actual exe as a best effort. - Josh: current_exe on windows is using git module file name - Eric: sounds like a good path forward. - epage: For unsupported manifest fields in scripts, we currently use a denylist. Should we use an allowlist? - Josh: we should arange so that when we add a new field to the manifest, when we haven't explicitly said it's allowed/denied in cargo script, cargo should fail a test - epage: how would you write a test? - Josh: It should not be possible to add a field to the manifest without specifying whether it is or isn't allowed in cargo script. - epage: sounds like you're suggestting we restructuring the toml package. That may work, but we need to look. - Josh: I see what you mean and I see how you got there. I'm imagining: is there some way we can put this in whatever metadata we already have on fields such that we catch this aoutomatically. - epage: We could move them closer together, then people could see that they need to update them in a lockstep. - Jacob: Seems a simple allowlist shouldn't be that much harder. You could build a hashmap with a boolean and treat the absence of the field as it crashing because we haven't decided whether this goes into cargo script. - epage: the pre-deserialization check is before the manifests. So we'd have to decide whether a field is allowed and we'd have to do a debug_assertion [...] That would be doable. - Josh: To answer the original question: it would probably be safer to move from a denylist to an allowlist. The worst case scenario for allow list is forgetting to update the list and showing an error message. The worst case for denylist is a field that's now suddenly stabilized. ## 2025-09-23 Out: jacob, epage, arlo (1/2) * FCP: https://github.com/rust-lang/cargo/issues/13051#issuecomment-3312988872 - weihang: It's instastable on beta right now. Do we want to add a -z option in case the FCP takes time? - Scott: we have about four weeks so we should have enough time - If it hits two weeks out, we'll want to revisit - I see epage has at least one concern out though - Dongpo: I looked at it last night, I didn't get epage's concern - Weihang: the host constant is different in cargo.toml target and crate - the host string for target is for target architecture - ehuss: Weihang, did you want to follow up on renaming it? - Weihang: we still need to addres the first concern - but renaming can address the second one - ehuss: Do you have any opinions about the first one? - Weihang: I don't know. I feel it should be fine, but - Scott: It's not as bad as `target`, it makes it harder to understand but it's not that bad - Weihang: You can just unset it and write down the concrete triple - ehuss: The concern is the directory layout, right? Because it separates the target and a host compilation and it has a different layout. - Personally I'm okay with it, but I understand. It's unfortunate we always had this split. - Weihang: It's unfortunate that you can't unset it - Scott: I thought we had that. - (backlog) https://github.com/rust-lang/cargo/issues/4841 — In windows, the program by cargo run called don't have JOB_OBJECT_LIMIT_BREAKAWAY_OK flag - (ehuss) Seams reasonable to me. - Scott: I think it's reasonable to have a third party thing not respect Cargo's `-j` flag. That's essentially what's controlling it right now? - ehuss: It's a bit different. We create these job objects to encapsulate processes. When we kill the process, we kill the whole chain. But there's no way for the process to break out of the job. The default of Windows is not to permit it and we just need to set the flag to permit it. - Scott: Can we set it for the final thing Cargo's running? I don't want to set it for e.g. build scripts. - ehuss: Yes. - Josh: Is this similar to a process group on unix/linux that's done as part of daemonizing? - ehuss: Not sure I know enough to answer the question well. It seems similar but more complicated than that. - Josh: Seems reasonable to allow this. It doesn't seem harmful in any way. - ehuss: With no objections we can approve that. - Weihang: should it be done in Cargo or job server? - ehuss: Cargo - (backlog) https://github.com/rust-lang/cargo/issues/4895 — Add cargo:rustc-dynamic-link-search for setting LD_LIBRARY_PATH during cargo run/cargo test - ehuss: we have rustc link search, that only allows you to use search paths in the out-dir - I'd have to see when this search but rust lib search does add this to the dlib path, but it only adds things that are in the out-dir - Ah, it is a request for dylib in the system - Weihang: If we set the dylib, it will break the isolation in the system - Josh: this seems like something for which we may end up with some weird compatibility issues - for example it's important to *not* set LB_LIBRARY_PATH to any system directories - checking this seems like a potential nightmare for us handling weird system configurations - if you're pointing to non-standard directories for running shared libraries, that should be handled by your executable - Weihang: and you can use pkg-config to search for libraries outside and have them automatically add it - Josh: That would be for compilation purposes, but this seems to be for runtime - Weihang: I think cargo also adds search paths for whatever was set in the build script so it's also applied to the runtime - Weihang: The other option is using the `[env]` table where they could set up `LD_LIBRARY_PATH`, but it doesn't support variable expansion - ehuss: Thoughts? I feel pretty uncomfortable with this but I don't to be in the way of people getting things done - Josh: The ask is having a build script to set this. The problem is that this is an end-user policy. The build-script doesn't know what that user policy is. We could support a lot of different options, but it seems like a gian pile of complexity. - We might consider trying to do a best-effort intention. Print an advisory message to say that we have a best guess to say that they may need to set the library paths for the compiled binary. - ehuss: That's a tricky part when using `cargo run` because it sets not just the library paths but also other environment variables that the binary may depend on and not run without. This is adding more to that and the binary will almost certainly not work without it. - ehuss: How about we kick this off to a "needs design" status. Ask someone to write a more concrete proposal that addresses the concerns raised here and then look at that proposal. - Weihang: That sounds more reasonable. We may also want more usecases for this. - ehuss: A few people put some usecases there, but more would definitely be better. It's also not clear to me how common this scenario is. - (backlog) https://github.com/rust-lang/cargo/issues/5305 - Add support for resource files - ehuss: They're asking for ability to have cargo build copy arbitrary files to the output - runs into: how much of a general-purpose build tool is Cargo? - Josh: This has come up with a number of different things that people wanted to do. And it seems the most general thing is a "post build script" - people want to include config files etc. - we could support a whole bunch of things and decide what we support or we could give people the ability to do what they want here - Scott: [epage](https://epage.github.io/blog/2023/08/are-we-gui-build-yet/) had a blog post about Rust install scripts. At the time his conclusion was: Cargo is not a general-purpose build tool, if you need that, you should use one. There's a lot of concerns about build scripts and their security. Adding another tool at the other end would add more issues. - Josh: Build scripts run on the dependencies. This is something you'd only do on the target you'd do for cargo install. - Josh: Thanks for linking to the post. epage mentioned that if we had artifact dependencies, this is just a build script. I like that idea. We'd still probably want a potential way to emit "include this additional file alongside cargo install" - Josh: If we had that and we had artifact dependencies, we wouldn't need new kind of scripting. - Dongpo: If we want to support this, we can also allow people copying a whole directory to the output - ehuss: Seems like it'd be reasonable to support - ehuss: I want to close this for something else (post-install scripts or something), does that make sense? - Arlo: Agreed. - Josh: When we've said Cargo to be a general-purpose build tool, we mean we don't want to support non-Rust things (go scripts, java etc.) But I agree that things directly adjunct to Rust (e.g. a Rust cli tool but we also install shell completion or man page) - Josh: I do think we should close this in favor of artifact dependencies. - Arlo: I like the idea of extending cargo install for the top-level package. It goes along with the idea of extending things for the top-level package. - Josh: The artifact dependencies are similar. For installing additional files with cargo install, there's a lot of design and discussion that needs to happen. That's not what's happening in this issue. - Arlo: Reading Ed's blog about things like MacOS's universal binaries. - Josh: We've effectively solved the MacOS universal binaries by waiting for so long that X86 is dying out on MacOS and they're going to deprecate and remove it. - Arlo: But the same thing could happen again. We should at least consider it for the design. - Josh: Sure. And it's a concern for Android as well. But that's the cargo-apk problem. - Arlo: Windows can also have this issue and they won't be ditching the x86 issues at the same time. - Josh: I'd be happy to put together a few comments and then close it. - (backlog) https://github.com/rust-lang/cargo/issues/5368 - Add the ability to open a specific module when running `cargo doc --open` - ehuss: You're working on some module and you open the documentation related to that module. I'm trying to think if this is something Cargo can do by itself... yeah it probably could. - Arlo: Based on my limited knowledge of rustdoc it feels like something that sholud be possible. - ehuss: In this usecase you're editing the source, editing the docs, don't you always have the documentation open and reload it? - Arlo: There's clearly some desire for it. But I don't understand why you can't navigate to it and refresh. - Scott: When I was doing annotate snippets to refresh it. - Tomas: The way I understand the request is they want an editor shortcut that would open a specific page without having to navigate away form code to the browser. Similar to having a shortcut that does 'cargo run' or that runs a spefific test you're working on. - ehuss: I don't know if there's a way to open a specific query in rustdoc. - ehuss: Sounds like you'd have to type out `--open --module` -- would Rust Analyzer do that for you? - Scott: Yeah, I think you'd have the tooling know you've got a module open and it would fill out that name for you - ehuss: If we're saying rust analyzer is responsible for running this command, Rust Analyzer would be responsible for opening the page to the correct page. - Scott: How does it know which page it knows to open? - Arlo: Does it make sense to provide this endpoint for non-Rust Analyzer and then have everyone use it? It would be nice to do it once correctly. - ehuss: Would having a live-reload help here? Instead of using `cargo doc --open`, you'd just use `cargo doc` and the page would reload - Weihang: Should we look for feedback from the Rust Doc and Rust Analyzer teams? - Arlo: Yeah, if we had their buy-in that'd be enough for me to accept it. ## 2025-09-16 Out: ehuss, tomas, arlo, dongpo - weihang: reproducibility when moving workspace - https://github.com/rust-lang/cargo/issues/13586 - https://github.com/rust-lang/cargo/pull/14953 - Do we prioritize path dependencies in lockstep with workspace or independent? - How does path-base affect this? - How does this affect what is shown? - Fingerprinting absolute path is safer (we move workspace, is it still pointing at same thing) - We still fingerprint the content - We get separate cache entries when the source id changes - Do we optimize for people with absolute or relative paths? This change would improve relative but break absolute. - epage: absolute is machine/os dependent, so less common - josh: but some companies do require it! - epage: but for mine, it was an anti-pattern we were moving away from - epage: for me, I never have non-member paths. Microsoft has it all the time. Where do we expect people to be in the middle? - Do we expand `~`? - epage: I doubt it - trim paths? - but not requiring it - Issue is focused on symbol name for reproducibility, not on rebuilding. - trim paths would be for fixing that - **That means we do have reproducibility issues when using trim paths and non-member path dependencies** - Put the design back onto them - Comment posted: https://github.com/rust-lang/cargo/issues/13586#issuecomment-3299052534 - (backlog) https://github.com/rust-lang/cargo/issues/4840 — Suppress missing description/repository/etc warnings when publishing to a custom registry - see also https://github.com/rust-lang/cargo/issues/4377 - epage pointed out user-controllable lints as an alternative. - (ehuss) this is tangled with the general problem of registry validation - scott: Can the repository tell us? - maybe in the index config? https://doc.rust-lang.org/cargo/reference/registry-index.html - include links for documentation? - josh: if linted ouside of publish, how do we know registry to publish to? - `publish = true` means "publish to any" which includes crates.io - https://github.com/rust-lang/cargo/issues/6153 - `publish = [names,registry]`, we check those - If we use config.json, you likely already have it - if you don't and we do this durign cargo build and `--offline` is set, then *shrug* - Reproducibility issue on when the lint fires - But this might bloat the file when its needed to be checked regularly - we have caching but CI with clean instance could be an issue - but if we move the lint to `check`, then we run it anyways - when to run lint? - today, publish - if `publish=false` is the default, then even `cargo check`/`cargo build` could give these lints if `publish = true`, so the feedback is more timely (e.g. before you push a tag) - for now, maybe turn off by default for non-crates? - cargo-safe-publish - https://blog.weiznich.de/blog/cargo-safe-publish/ - submodule being dirty part seems reasonable - asked them to create an issue and they don't want to talk to us - someone needs to create an issue - untracked files being dirty? - changed package - we could checksum before / after - besides security, could be a good sanity check in case something else affected it - when we tar, we do it directly to disk - publish also streams from disk - Their dry-run -> regular publish approach is racy ## 2025-09-09 - Build scripts slow on macOS due to SIP / developer tool execution policy. https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F/with/536245777 - https://github.com/rust-lang/cargo/pull/15908 - Discuss further, consider the messaging - epage: having it as a note and be comfortable with the wording I'd be fine - be great if we could turn off advice from the CLI rather than asking people to edit a config file - concept from git: it's not a lint, more of a message that can be useful, but can be turned off per message - Weihang: can it be a lint group? - we don't have linting for ?? - there are other things where advice tables came up - feels less like litnting and more like a granular verbosity control - ehuss: we can leave comments on the PR, the messaging needs a little bit more work - this doen't affect just Cargo, it affects everything you can type in the terminal - epage: you can't have a more granular configuration to control explicitly? - the messages sounds like there's a sentry for cargo so you can more narrowly scope it - we need to check the exact behaviour and make sure the message matches - epage: parallel fetch of git - https://github.com/rust-lang/cargo/issues/15934#issuecomment-3263588698 - Requires a `Sync` GlobalContext, so would https://github.com/rust-lang/cargo/issues/15676 - Progress bars might be wonky - Error handling is a concern (the original motivation given for it beign serial) - Their branch has more changes than I expected - epage: most of the benefits would be also gained by shallow clones - but then doing it parallel would also benefit challow clones - Weihang: isn't shallow clone blocked on github side? - epage: it's not blocked on github, it shouldn't be a problem - but we need to make sure everywhere we do git operations it works - but converting to a full clone from shallow can be expensive - Jacob: it's also not clear how much github cares anymore - we're no longer using it for index so it's not the primary way people interact with github now - epage: we may have to switch to OnceLock if the current tooling doesn't support nonSync - it shouldn't be too difficult and the performance hit shouldn't be noticeable - ehuss: sounds at least worth doing an experiment for - weihang: do we think the progress bar is a blocker for this? - downloading will have multiple progresses - epage: the idea is that the longest progress bar would be the one that's show - and they're using rayon rather than our pre-async asynrc architecture - weihanng: maybe showing a combination of the progresses of all the downloads - epage+ehuss: yep - epage: we could have them parallelize the manifest parsing first - that's a smaller milestone but at least it's motivating for `GlobalContext` - ehuss: makes sense to me - epage: color and annotate-snippets - I started to migrate some messages cargo's using to annotate-snippet - consistency with rustc - move the warnings to lints - our note color is now the same as our header color - right now the goal is to output the same colors as rustc and then open discussion about changing some of them - I'll be splitting the PRs, there's a lot of messages we'll want to do - ehuss: all that sounds good to me, I don't have any strong opinions - Weihang: we should have an error message writing style guide eventually - epage: there's rustc's styling guide - ehuss: Ed brought up a small summary of what your strategy was - it was good, I wanted to make sure was everyone here was aware - but the general gist was to match rustc and its style and that sounds reasonable to me - epage: at some point I'll be playing around for a replacement for anyhow that allows an error to allow better diagnostic annotation that can be integrated with annotate-snippets - I think having chains of "caused-by" is a terrible user experience - turning those into notes and snippets and other things to be more user friendly on how we format this - it's part of the overall direction of this annotate snippets thing I'm doing - Weihang: what about libcargo? - epage: programatic error messages are difficult, for a project of this size they're even more difficult - https://github.com/rust-lang/cargo/issues/10160 -- being able to match on specific errors. - epage: that sounds less about API usage and more about improving the quality of the error reports - ehuss: rustc uses this custom derive proc macro and then has these translatable diagnostic files - I found it difficult to translate that - there's a lot of cumbersome indirection - the translation efforts have officially been halted - we need to be careful about how complicated the programatic error handling can be - Weihang: where was the announcement of pausing localization effort? - ehuss: it was an MCP - epage: RFC owners? - is there any conversation to follow-up, where are we going with this? - ehuss: It should be clear to everyone that Cargo is responsible for decisions about the manifest format - but if they're blocking progress, that's not great - Jacob: that sounds like they should be CCd on the RFC rather than being added by the rustbot - Weihang: Do they want to check their box or just being kept in the loop? - ehuss: couple options - I could do a public message on the RFC pushing against the actuon and see how it goes - or I could go to one of their team meetings and have a sync discussion - Weihang: or onece we've resolved concern, we caund get them check their boxes - epage: They refuse to remove inactive members so they can't get their boxes checked - that's why they don't use FCPs - they hold synchronous meetings instead - Jacob: Can we change the bot that when there's a cargo RFC happening, it notifies their channel? - they wouldn't be voting but they'd be in the loop - (backlog) https://github.com/rust-lang/cargo/issues/4505 — Add option to set environment variables only for being run process - Previous attempt was rejected: https://github.com/rust-lang/cargo/pull/4557#issuecomment-334374427 - `[env]` was stabilized in 1.56 https://github.com/rust-lang/cargo/pull/9411. This can be used on the command-line, such as `cargo run --config env.MYVAR=\'abc\'`. Is that sufficient to close? - ehuss: you can't do everything, it doesn't set env vars for cargo itself, but it should handle the rest - epage: I think the main intention on the generated binary and nothing else - ehuss: since we now have a solution and the proposed idea was rejected in the past we go ahead and close it - epage: They'd need to put a case for why the env table isn't sufficient, in the meantime I'd be fine closing it - epage: just setting env variables is not sufficient -- you may need to clean them, choose which ones to inherit etc. - (backlog) https://github.com/rust-lang/cargo/issues/4663 — Automatically enable required-features - epage had some suggestions on how this could work, with "Add a `--required-features` flag" and "For `--bin`, `--example`, and `--test` flags, enable the required-features" - ehuss: any quick thoughts about this? - epage: those are the best options I could thitnk of that honor the needs of different users - ehuss: was there some reason not to do this? - epage: you had concerns around `--bin` because it doesn't honor the order of the operations - Weihang: maybe we can add another new option "per target" to the unstable features? - but that might hurt the performance of entire build time - ehuss: to move forward, how about we add "needs-design" and have people experiment with what epage proposed ## 2025-09-02 Cancelled due to rustconf.