Cargo team meeting notes October 2025

--- robots: noindex, nofollow tags: meetings --- # Cargo team meeting notes October 2025 ## 2025-10-28 - Scott: Use test name for test directory in cargo's testsuite - https://github.com/rust-lang/cargo/pull/16121 - Scott: Right now you can't really debug a test easily. It'll go into a random-generated path is. This change makes it that that the directory for a test is a tests directory and a name of the test. - On Windows, this is running into path length limits. So we still keep that fallback for windows but for the other platforms we want to improve the user experience. - But I know that Eric and Arlo use this - Scott: I was debating an unstable environment variable that you'd flip it back. - Josh: What is the usecase that doing this would break? - Arlo: If you use the old scheme, you delete everything in the test folder, run a single test and then the name for this will always be called `t0` - epage: You have clean everything and run a single test for this to work. - Josh: Could we have the test suite detect if we're running exactly one test and symlink it to `t0` or something? Special-case running the one test. - epage: Or we could do that for the first test always. - Scott: We don't even have to put it under `t0`. We can name the special test anything we want in theory. - Eric: If that's not too hard, that'd be nice. It would be more convenient to be able to consistently work on tests in such a way you don't have to run a bunch of shell commands to set up your environment. - Scott: I'll probably leave it at t0 and set up a symlink or something. - Eric: The Windows will use the old behaviour, is that correct? - Scott: Yes, that way we won't run into the path length limitation. - Scott: It's two separate implementations so we're not changing anything for the old one. - Josh: As of relatively old versions of Windows 10, it's possible to work around the path limitations. - Scott: Cargo enables it for itself with a build script, but we can't set it for the individual test binary without having the same build script run on all of those. - Arlo: It might also not allow you to set the working directory - Eric: Yes, you'll run into a lot of problems. - Scott: I'll find the way to support at least some way to run a specific test in a debug folder. - 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 - Josh: What are our next steps are for stabilizing this and the corresponding options iff rustc stabilizes the underlying options - epage: tracking issue lists two unresolved issues - it's not reading profile from `.cargo/config.toml` - we've discussed challenges with the layering scheme, we need to figure that out - Josh: I can look into the cargo.toml - epage: The other one is - Scott: The lint might not be stabilized at the same time. If it's not stabilized before, it might not fire correctly - epage: Do we want to block on it or just mention in the tracking issue - Scott: I'm not sure we want to block on it, but people were doing it even when we've told them not to in the blog post - Josh: And it's not an issue with the specific lint but with linting in general not being stabilized yet - Eric: Josh, did you have any particular concerns? - Josh: I did not, just wanted to check if folks wanted to let it bake more. It seems not, but I need to fix the unresolved issues. I'll follow-up with you on the config.toml issue. - Josh: When you turn on the unstable option when you publish, will it publish it or will it automatically strip it because it's unstable? - epage: It will strip it during publishing - Josh: So I don't think it's a blocker necessarily (it'll go away once you stabilize), but the point of hints was to work even if an older version of cargo doesn't understand them. Not interact the same way with the nightly mechanism. An unknown hint should always just be ignored. So it'd be worth looking into how to not make this getting stripped out. - Josh: That covers the item we needed to talk about live. I appreciate this. We can do the rest async. - Eric: I'm running `cargo package` and it doesn't strip it. - epage: It's about dropping unused manifest keys on old versions. It's not on a per hints basis but on the whole hints table. I don't think there's any new problem for any new hints. - epage: We do have unused manifest keys for the hints table. - Josh: So we should fix that so we'll have this work for any future hints. - Weihang: exclude `.gitattributes` in subdirs in `cargo vendor` - https://github.com/rust-lang/cargo/issues/16148 - Weihang: We only filter aout the `.gitattributes` in root but not in subdirectories when you run `cargo vendor`. Whenever you run `cargo vendor` on Windows, a checksum can change and vendor will fail. I think we - Josh: If we're already stripping them from the top level, we should be consistent. Either we strip it everywhere or not at all. - Weihang: And git is currently the only VCS we support, right? - Josh: At this point I don't think `jj` does anything new that doesn't use git. If that changes, we can have an enthusiastic person to do this. - Josh: What is it that we're trying to do by stripping out the gitattributes? - epage: Line endings. It can change the contents of the files in your vendored directories which will then fail a checksum. - Josh: There are some gitattributes in the Rust project that determine whether a file is text or binary. This isn't a blocker but long-term I wonder if having a safelist of attributes we do preserve would be desirable rather than blocking everything. - Weihang: something like `vendor/include/config.tom`? - Josh: Whether it's configurable or not, having a default list of what's okay. - Arlo: That would get us into a business rewriting the attributes files. - Josh: It's not a blocker now. - Scott: How should we handle a user wanting to use unstable emitter flags (unicode diagnostic output, or use the old emitter when `annotate-snippets` is stablilized). - Scott: There's no current way to specify an unstable emitter in cargo. There's also no way to control it in the future. What if they want to support unicode but not unicode output? - epage: In my opinion it's like color -- it's all or nothing. - Scott: Once annotate snippets is stablized, we may want to fall back to the old version? - Josh: If this is passing the tests, producing the output people expect, I don't see any good reason for people to have the support for rolling it back. - epage: You can't use rustflags to set emitters, so I could see an unstable option to set an unstable emitter - Scott: How do you set this for the unicode emitter? - epage: Do you want to generalize this to any emitter or just unicode? - Scott: I can't think of anything else right now? - epage: How about we add a flag - Scott: It existed for a year but it has a lot of bugs. I fixed some of them. When I switched rustc to unicode, then diffed it with annotate snippets, the annotate snippets was more correct. - epage: I would just add a new `-Z` for this. - Scott: How would you set it in a config? - epage: There's a section for unstable configs - Scott: Does anyone think I should stabilize annotate snippets to be unicode? - epage: It's already on stable, it's okay to switch to annotate snippets. - (backlog) https://github.com/rust-lang/cargo/issues/5866 - Cargo metadata doesn't include actual filename of binary targets - Arlo: is this where they need to know what the binary will be before we start building the target? - Eric: Is there anything that would preclude us from doing this? There's no hashes or anything we'd have to worry about? - epage: What files do we include with this? I think in `message-format=json` we include all the files. Figuring out a one artifact the person cares about is very usecase-specific - epage: It looks like we have an actual specific executable field within the JSON messages. What do we do this for other (nonexecutable) files e.g. dylibs? - Weihang: Or do we want to revive `cargo query`? - epage: `query` is about people passing the buck to us. It's not going to offer us any magical benefits. We want to have our plumbing commands and have people build things on top. - Josh: in rustc it makes a lot of sense to make queries because the system is running and keeps that around. For Cargo, the question is "how do we avoid redoing the same work if we do 12 queries"? And we don't have a cargo server running in the background. - Eric: One complication: `cargo metadata` doesn't have a target config flag. - epage: Sounds like what they need a "resolver v2". And again, that would be plumbing comments. - Arlo: If it doesn't work for cross compilation, we should not make it available now. - Eric: We could add `--target` to `cargo metadata` but that would be complicated. - Eric: Is there a proposal for what we could do instead? - epage: I'd point people to the plumbing commands and say they could always help implement these. - Arlo: When did we add the json output that points the executable? Was that done after 2018? - Eric: Based on my comment, you could use it then. I ran into this on a few occasions: I don't want to run a build just to get a pathname. But it's not easy to shoehorn it into something else. - Eric: Is there somewhere we can point to for cargo plumbing? Our unstable docs and repo links to the cargo-plumbing command: https://github.com/crate-ci/cargo-plumbing - Eric: What do people agree of closing this and pointing them to cargo-plumbing? - Arlo: If we agree we want to support this in cargo plumbing, then this is reasonable. - Eric: This is similar to "needs design" work. It's not something that can be easily added to cargo metadata. - epage: I can see us either closing or keeping it open for tracking purposes but redirect it to a cargo plumbing command. - Eric: That sounds good to me. - (backlog) https://github.com/rust-lang/cargo/issues/10875 - Can't publish to our crates registry if git is also specified - epage: on publish of registry-only dependencies, we replace `registry` with `registry-index`, seems like we should support that here as well - epage: We error if you specify registry and git at the same time. - Eric: There was a similar issue posted yesterday, wasn't there? - https://github.com/rust-lang/cargo/issues/16161 - epage: That's what made me think of this and linked it there. - Eric: What did the other issue want? - epage: They'd like being able to keep the git dependency alive for the publish. - Arlo: One wants the git dependency stripped and the other one wants us not strip the git dependency. - Eric: That sounds like what I'm reading here. - epage: Looking at the fact that we support two different overlapping usecases and don't support them together seems strange and we should be able to work with them together. - Arlo: I think I agree with less but I'm less in agreement about what kornelski wants. The first request seems reasonable though. I want to do something with a third-party registry that I can do with crates.io - Jacob: In the case of crates.io we know the git repo, we don't know what the other registries do - epage: How do we know whether this registry supports it or not? It needs design work. We can at least unblock some people here. - Eric: I agree. If we support this for crates.io, we should support it for other registries. For the issue kornelski has, we'll need to do more design work. - epage: In his later comment, he talks about people setting a version that isn't needed for git dependencies. - Eric: We could have a lint for that. - epage: The only way I could think of it being a lint is if you aren't a publishable crate than you can have the version not set. - Eric: Exactly. Let's have the other issues marked as accepted and mention we need a little bit more understanding for kornelski's request. - (backlog) https://github.com/rust-lang/cargo/issues/5881 - Allow setting linker args that only apply to bin or lib targets - Weihang: can they do that through a build script? The link-arg instruction? - Eric: Can you set that per target? - Weihang: I think test has a different variation for the link arg. - Eric: Link-arg-bin. Yeah, that might be the answer. - Arlo: Yeah that looks like the answer. - Weihang: I don't like the way to needing a build-script to pass a link-arg. But yeah, it should work here. - Eric: I'm not familiar with pyo3. We can ask them to see if their documentation has been updated or something. - Eric: I'll poke around this a little bit and then ask a question. Or close it. ## 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.