---
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) on `rust-lang/cargo`, or [**I-cargo-nominated**](https://github.com/rust-lang/rust/issues?q=label%3AI-cargo-nominated) on `rust-lang/rust`, to add them to the agenda.
[**FCP/Nominated/RFC Status Overview**](https://github.com/orgs/rust-lang/projects/47)
## 2025-12-16
- (backlog) Option for cargo run to run the binary in a specified working directory
- https://github.com/rust-lang/cargo/issues/15789
## 2025-12-09
- FCP Reminders:
- build-std: context https://github.com/rust-lang/rfcs/pull/3873
- feat: stabilize -Zconfig-include https://github.com/rust-lang/cargo/pull/16284#issuecomment-3563644951
- fix(package): Don't verify registry for --list
https://github.com/rust-lang/cargo/pull/16341
- ed: Tracking Issue for _pubtime_
- https://github.com/rust-lang/cargo/issues/16270
- How should we deal with Summary pubtime parse errors?
- Currently, the field is ignored if it errors, mostly to avoid having `jiff` be a dependency of `IndexPackage`
- How strict should we be on the Summary pubtime format?
- It is a [`jiff::Timestamp`](https://docs.rs/jiff/latest/jiff/struct.Timestamp.html), e.g. `2020-08-21T02:21:58-04`
- What precision do we want?
- crates.io originally implemented fractional seconds on accident
- Ed: Small enough that we can hopefully stabilise without index format
- Ed: Allows cargo generate-lockfile to have a publish-time mechanism
- Josh: Do you think the necessary data will be there so crates.io can populate the index entries?
- Ed: I think it will but we need both teams need FCP this
- Eric: If the field is missing, what do we do?
- Ed: If there's no time set, we don't apply any time filters. If the field is error we won't consider it valid for any time period
- Jacob: It should be possible to backfill from the git index
- Ed: I think they have publish dates for all their packages
- Josh: There's actually a tool in the latest version of git that efficiently navigates commits and figures out blame date for every file -- check the latest github summary of git release notes
- Josh: If anyone wants to backfill their nonstandard indexes, this could help if they have a git backing
- Jacob: How did the crates.io conversation go?
- Ed: I tagged Tobias who jumped on the imlementation right away. So I'm trying to keep the momentum while there's excitement
- Josh: Sounds we want to specify the time travel feature sooner rather than later
- Ed: There's a separate issue for us having a minimum release age, but we have a way to unlock both of those
- Jacob: It might be good to do absolute dates and then six months from now go with relative dates
- Ed: If you want to time-travel, cargo generate-lockfile is the best approach,
- Josh: I think I've seen a rust crate for parsing relative dates
- Ed: We already have that within cargo
- Josh: What are we using for that?
- Ed: I think Eric rolled his own
- Eric: It was just a number followed by a label, nothing special
- Josh: so an 'n' followed by a unit?
- Eric: Yes
- Jacob: Do we want to open a zulip thread on their channel asking how they wanted to do this?
- Ed: Once we've had it sorted here I was going ot ask them how they want to handle it
- Ed: Back to the first question
- Josh: We have a specified format for that field and we've defined how it should be set. If it's missing we should treat it as not having a timestamp. The only reason I could think of parsing it in a lax manner is if we want to change it in the future and handle that, and we could version it if we wanted to change it.
- Ed: I thought that was going to be the answer, I wanted to double check. Also, if there's a parse error it throws out an entire summary. We have a recovery code but the parse message is not shown to the user.
- Ed: The next question: the pubtime format itself: what do we define and what is it we parse? We're using a jiff::Timestamp currently
- Ed: This is what Tobias suggested for the specification of the crates.io field actually is: `ISO8601 with UTC timezone (e.g. 2025-11-12T19:30:12Z)`
- Ed: Thoughts on our implementation vs. what we specify?
- Weihang: the difference is one with the timezone and one doesnt't?
- Ed: Yes, one has the timezone and the other specifies the TZ information with Z. I also don't know if we allow replacing `T` with a space or not
- Weihang: I feel we should be as strict as possible to avoid ambiguity
- Josh: ISO 8601 is not particularly readable, but this isn't meant to be human-readable
- Ed: I could handroll a format for this
- Jacob: I'm surprised jiff doesn't have a strict mode. We should talk to him before handrolling our own
- Ed: There is a `strptime` so I could use that to get a strict mode
- Ed: Last question: precision. Originally specified as whole seconds, crates.io has whole seconds. I'm assuming we're fine with whole seconds. We're not providing atomically incremented sequence numbers for publishing.
- Josh: Whole seconds seem fine. I think we should have precision for seconds and minutes. For things like doing a time bisect. If we only had day or hour, there'd be a lot of changes batched together. But anything more than seconds doesn't make sense, the overall crate upload process isn't going to be that precise.
- Ed: It wouldn't make sense to lose seconds precision, it's that in the format the subsecond precision is optional and we wouldn't be using it.
- Weihang: If someone wanted to specify a ms precision, they can just pin a version
- Josh: I think it makes sense for server timestamps to always be in UTC. But on the client when doing filtering, we should take things like local timezone, DST etc. into account
- Ed: The index format doesn't need it at all. What would be stabilized now would be UTC. It's the two features on top that might need it.
- Jacob: Could this be used in the TUF discussion? Adding a unique ordering to every entry would help unlock something.
- Ed: In theory you could have two package with the same timestamp.
- Jacob: I think it'd be possible to have two versions of the package with the same timestamp
- Jacob: What does this has to do with yanked packages?
- Ed: We don't track handling yanked stuff yet. We'd need to track the full history (when it was yanked, when unyanked etc.). A future things is looking into that
- Jacob: Whatever documentatino we put in the index format must clearly specify that
- Ed: This is the original publish time not the last update time. I'll add this to the note.
- (backlog) Support inheriting `metadata` from workspace `Cargo.toml`
- https://github.com/rust-lang/cargo/issues/16183
- Various concerns listed in the issue about the metadata table is opaque, and the inheritance behavior (and key clashes) would be unclear.
- Ed: I'm sympathetic to the idea of being able to inherit the docs.rs configuration. If you're doing local dev it can do its own workspace inheritance. But when you're doing a release it doesn't have access to the workspace metadata table
- Josh: Doing workspace inheritance after the fact like that instead of modifying what we upload to crate.sio is inconsistent with what we do elsewhere
- Ed: But how we do workspace inheritance is when we dont know the behaviour of the tools than want to do it
- Josh: Elsewhere we do workspace inheritance and allow to do it locally too. It seems we should have a way to specify inherited keys outside of the metadata table. e.g. metadata workspace = (list of keys). And if you specify the key in the metadata table we would override the table, we don't do merging.
- Josh: You can take an entire branch of the table, copy it from workspace and then override pieces of it, but we can't do merging of any kind. Just copy and modify
- Ed: Generally, the package we present before publish has workspace inheritance resolved. If cargo metadata shows that field, that copy will ahve been resolved and it would show it
- Scott: Could we only do this for docs.rs for now?
- Josh: as long as it's in metadata, that's a wild west
- Ed: We have different designs: defining metadata keys you want do copy, the inheritance in the issue. So sounds we need to flip this into a `needs-design`.
- Eric: Sounds like a good idea.
- Josh: Whoever's doing a wrietup should propose the syntax for this and then we can decide if we have objections we can bikeshed. But if someone picks something we may all be fine with it.
- Josh: Do we have a catalogue of observed metadata usage we've seen in the ecosystem?
- Eric: I don't know
- Ed: We can list what we came across but I don't think we've done a systematic overview
- Josh: Given the local copy of each crate, it would be great to have a histogram of the common metadata. What types of metadata people commonly have to see if there's anyythnig with weird behaviour before we stabilise that
- Weihang: Tools usually use their own config file format rather than using metadata. E.g. nexttest has their own `nexttest.toml`
- (backlog) pre-run and post-run hooks for cargo
- https://github.com/rust-lang/cargo/issues/15888
- Ed: This worries me. These hooks are running at the beginning and very end of the command. They can see our commandline, parsing it and doing something with it. We're blesing people parsing our commandline and that's a context dependent pars and a very brittle thing. Adding a new feature now means breaking people using this. For post run hooks that that could cause issues for `cargo run`. There we do straight `exec` where we're no longer running the cargo process. There's nothing to run the hook.
- Weihang: Jacob and I had experience running hooks. But we didn't use hooks, we created wrappers for actual cargo processes. It ran into a lot of problems (e.g. running recursive cargo commands).
- Josh: I'm getting the impression of someone decided how it should work, telling us how it should do. Towards the end they told us what they actually want (they're trying to wrap cargo and notice after cargo has run that the lockfile has change and they want to associate the lockfile with what command that was -- so they could log changes to the logfile). I think this is a bad idea but I think I understand what they're trying to do.
- Josh: I think they found themselves in an XY problem. We should not be enabling this feature. If you need a comprehensive log of what Cargo want, you could use a wrapper (which they do). For tracking the lockfile changes, that sounds like a version control thing. I suggest to close this issue and recommend they drop by the Office hours and they can tell us what problem they have and then we can figure out if there's a sensible way to do that.
- Jacob: Also, if you want to know what runs on your system, you don't ask cooperative tooling. There are allowlisting tools.
- Ed: In this case this is about language agnostic tooling. They want to advertise to their users e.g. "I updated my version of protobuf"
- Ed: Sounds good to me to close and point them to office hours
- Eric: Sounds good to me too. Other package managers do have these hooks (javascript, linux package managers) but it doesn't fit here.
- Josh: But in those cases they don't allow access to the command line but rather specific actions.
- Weihang: Maybe instead of hooks we could have a `configure` command where you could specify everything cargo would do. So you'd run this before building.
- Ed: One of the beauties of cargo is not having to do any initialization before doing something.
- Weihang: But sometimes people need to do something ahead of time and they need to use something like make
- (backlog) Request: shorthand CLI flag for `--no-default-features`
- https://github.com/rust-lang/cargo/issues/15867
- Josh: I appreciate not wanting something long to type here. But we keep meaning to redesign this anyway which makes me want to not try to add a short option for this version of it.
- Ed: Do people really type `--no-default-features` all the time?
- Josh: I do it frequently but I typically find it in a shell history
- Ed: I typically only do this when CI fails
- Josh: I test no features, all the features etc. to test -- especially if I'm adding a new feature to a crate I don't own
- Josh: Once we have negative features, could this be just: `-F "-default,feature1,feature2"`
- Ed: I'll write it up
## 2025-12-02
- FCP Reminders:
- build-std: context https://github.com/rust-lang/rfcs/pull/3873
- feat: stabilize -Zconfig-include https://github.com/rust-lang/cargo/pull/16284#issuecomment-3563644951
- Scott: wanted to talk about the cargo-team repo poll Eric put up
- Eric: we'd put team notes there for starters
- Scott: Wasn't there another team that did this a while ago?
- Tomas: Several teams have `-team` repos. On my backlog to port the old hackmd to the repos.
- Eric: There's about a dozen teams that have team-specific repos they put things to
- Scott: I remember reading about HackMD syncing with a github repo. Might be worth investigating.
- Scott: Do we have old notes?
- Ed: We could archive old notes or design docs
- Ed: Since other teams use theirs for change proposal, we should note ours won't be there
- Josh: Yes, until we have a specific idea in mind on how to use GH Issues, we should just keep them turned off to not confuse people. For now rust-lang/cargo is what we're using now
- Josh: We currently move things we didn't talk about up to the next meeting's date heading. We should make sure to do that *before* we archive the minutes, so that the archive of the minutes reflects things that we actually talked about, and move the rest to the next meeting so as not to confuse people (who might think we talked about everything in the meeting notes).
- (backlog) Workspace crates should have an implicit patch for crates in the workspace
- https://github.com/rust-lang/cargo/issues/6126
- ehuss: It seems to be that workspace inheritance largely solves this problem for me.
- epage: for cargo, this would cause `home` to switch from registry dep to a path dep
- epage: what version is even put in the lockfile that the implicit patch has to match?
- patches don't work when the local version is higher than the registry version
- epage: two styles of workspace development: path dep or patch (https://github.com/rust-lang/cargo/issues/15180#issuecomment-2738023635)
- I remember there being a reason why blessing the patch workflow would be tempting but can't remember it atm
- Ed: I've seen 2 workflows: first you have path dependencies on everything or you have registry dependencies and you patch everything
- Ed: I think there's more fundamental problems with the patch flow. You need to patch a version that's in your lockfile and that needs to be in the registry. If you made a change and didn't publish it, you can't use that version as patch.
- Ed: I think we should go ahead and reject this
- Weihang: I remember stdlib also uses patch for something.
- Josh: People often want this for vendoring. I vendored a couple of crates to my workspace, modify them and want to reference using their version
- Ed: I'd say have a specific patch for that situation
- Josh: That's fair but people are expecting to be use the vendored thing. Maybe we could teach cargo vendor to generate the patch version?
- Ed: cargo vendor will take all of your dependencies. If you're only doing a couple crates, something like cargo override might be better suited.
- Josh: I see, I thought cargo-vendor had an option to just vendor a specific crate.
- Ed: I'm not seeing that on the commandline
- Jacob: If we want our config files to express this and people are having a hard time, maybe we can have tools that do this with good UX. Maybe we could use something like cargo-add or have it suggest adding a patch to vendor it?
- Eric: That sounds like the cargo-override command?
- Jacob: Setting a patch is an annoyingly different to setting up a dependency
- Ed: Cargo override sets up the patch as well
- Ed: If you need a dependency writable on a short-term, you need to put it in the editable mode
- Josh: having a first-party tool that clones your dependency locally and sets it up would be great because it'd let us steer people to the workflow we recommend
- Ed: cargo override right now points to the directory or source. I've provided feedback about being able to bring in other related packages, on looking at the hash or .crate file -- this depends on your workflows.
- Jacob: That makes perfect sense. We should do all of those and then debate defaults some other time
- Ed: I've provided some feedback, we'll see how that goes. People don't know it. And we'd need to come up with a good name. cargo-patch would be ideal but it already exists on crates.io doing something else.
- Jacob: Should steer people towards easier contribution upstream, too.
- Josh: I'd want to see us doing that by cloning the git repository, doing their changes in git, and then pointing them to e.g. the `gh` tool to contribute upstream
- Jacob: I agree that's a great default, but Ed pointed out differences between repo and the crate file for example
- Eric: I hear you Jacob, adding patches can be difficult sometimes. This is a bit different and there seems to not be appetite to doing this right now and there are tools out there for solving this.
- Arlo: It's less frictiony in some places but it could also cause confusion on where something's coming from
- Josh: It's also valid to have a local package with a name that conflicts with crates.io and you don't want those two tied together. Seems it'd be better to curate people's patch section rather than
- Ed: In a previous discussion we talked about cargo new adding workspace.dependencies in the workspace members and `cargo add` using that automatically.
- Wrapping here to avoid doing further design work in-meeting
- (backlog) cargo test occasionally leaves a file descriptor open when exec'ing a binary on Mac
- https://github.com/rust-lang/cargo/issues/6344
- eric: More detail in https://github.com/rust-lang/rust/issues/95584. Last time I looked into this (~2022), there was no solution.
- See also https://github.com/python/cpython/issues/109154 for a discussion of using POSIX_SPAWN_CLOEXEC_DEFAULT. Unfortunately that looks like it requires some explicit registration of fd's to inherit?
- Thinking this would be closed in favor of standard library issue. I can't think of anything we can do.
- Though it isn't clear why an fd is leaking, especially inconsistently. `cargo test` is single threaded, so there shouldn't be any race.
- Eric: I've not seen anyone propose this recently. Propose we close this. This would be a change for the standard library.
- Josh: Given a 2018 issue reporting a problem, we should close the original and ask for a specific reproducer in a new issue if someone runs into it again. Using a FD allowlisting for inheritance isn't a bad idea.
- Eric: The difficulty is that cargo doesn't know which filedescriptors need to be open. E.g. jobserver FDs are hard for Cargo to know. And when using `cargo run` all FDs could be valid.
- Josh: I agree for `cargo run`. I was thinking specifically for `cargo test` -- there we should only inherit things we know should be inherited. These days, most build servers (one of last users of FDs) have mostly been replaced with env vars pointing to specific named socket
- epage: win7, a tier3 target
- I wanted to check in on this. Someone is trying to expand our version requirements so they could use home crate on Windows 7. How much should we be helping out on tier3 targets. We could add a new call to windows-sys and we don't know if the version requirement is still valid
- Weihang: are they asking for home crate or cargo?
- Ed: They're getting the home crate through other dependencies. I suggested `cargo upgrade home --precise`, it's unclear about what exactly's going on. The question is how much effort do we put to helping with tier3 targets
- Josh: It's not just "tier 3 target". If someone proposed a patch on an nintendo DS. But here they're asking for a support for something that's an older version of something that's a tier 1 target. We don't test this in CI and we do support the new one. The overlap could be a source of breakage -- our work maintaining the Tier 1 target is likely break the older tier 3 target.
- Ed: When there's overlap on a platform between Tier 1 and Tier 3, they could conflict and make it onerous for us to support the Tier 3 target
- Josh: exactly. Three things here: (1) someone asking for home crate -- that's where we can steer people to the standard library, no good reason to use `home` unless you need the cargo/rustup home, (2) they link to the windows-sys crate and said windows itself was making recommendation to use a range instead of the carret `^` requirements. Can we ask them to stop this?
- Ed: I've had people coming to me asking this. This makes more sense for -sys crates.
- Josh: The cargo resolver issues that make it flap between versions when you run cargo update.
- Arlo: Is that an issue with cargo that causes this flip-flopping we can fix?
- Ed: When we reuse a lockfile, we don't track you're reusing this package with this path. We just look at the package. So depending on how you walk the dependency tree, it may choose one or the other
- Arlo: Can we convince the windows-sys people to stop making so many breaking changes?
- Jacob: You may have better access to the people, can you reach out through the backchannels?
- Weihang: They also said they wanted to patch older versions of the crate
- Jacob: Unfortunately, you can't patch to the same source
- Ed: It would be great to solve this, but it's a hard problem to solve
- Scott: Interestingly, this is tier 3 without any host tools support. It should be something you should cross-compile for.
- Ed: It was marked as host tools support.
- Scott: That was made 3 days ago. I looked into that already. (I was wrong about this it was a month ago see [rust#148362](https://github.com/rust-lang/rust/pull/148362))
- Eric: What do we consider tier 3 support to mean?
- Josh: Tier 3 should be 100% support should be on the people maintaining this target, it's also not supposed to disrupt any work on Tier 1 and Tier 2 targets. We want to make sure that people are unconstrained breaking tier 3 targets.
- Ed: The weird case was that this is just a dependency upgrade.
- Jacob: I suspect windows-sys will not be interested as Windows 7 is not supported by the company
- Arlo: I agree. They may be more amenable to doing fewer breaking changes, but even that's not trivial
- Josh: semver checks would probably do a good job on this
- Ed:
- Josh: The Windows 7 target has a note saying "host tools may work but it's not guaranteed". Can we tell people maintaining host tools to not say that? This makes people think that this is supported. If you need to run Windows 7, we can say "don't use host tools, cross compile"
- Arlo:
- Josh: I think it would be good if the standard library used windows-sys instead of writing things by hand. But they don't do that now.
- Josh: Can someone take the item to talk to the maintainer of the Windows 7 target and ask them to remove the host tools note?
- Eric: I don't know how that decision gets made. I support you Josh, it's unreasonable to have host tools work on Windows 7. But I don't want to get involved.
- Jacob: Is the box prescriptive or descriptive? In either way it should be removed.
- Josh: I'll reach out and ask them if they could please address this.
- (backlog) Create .gitignore even if inside existing repository
- https://github.com/rust-lang/cargo/issues/6357
- See https://github.com/rust-lang/cargo/issues/11548 — instead of writing a .gitignore with /target -- output a .gitignore with * *inside* target/
- epage: original request is still a thing for other VCSs
- https://github.com/rust-lang/cargo/issues/15060 -- PR to put gitignore inside target
- https://github.com/rust-lang/cargo/issues/15061 -- Issue for self-ignoring target. Variant compared to 11548 that it is in *addition* to creating the top-level gitignore.
- Eric: This person is creating multiple cargo projects and they want each to have its own `.gitignore`. There's multiple open issues of people wanting similar things.
- Weihang: I think putting .gitignore in the target directory is interesting. It'll always be there
- Eric: This is similar to what we talked about when backup files
- Jacob: What hapens in git when you .gitignore the folder it's in? .gitignore doesn't work until you `git add` it.
- Jacob: You end up `git add`ing the file even though it's in the gitignore because you added it explicitly
- Josh: We used to add the lockfile but we don't do that anymore
- Eric: In my testing I don't see the same behaviour as you've mentioned, Jacob
- Jacob: I have strong memory the other way but you have actual evidence. I trust you guys.
- Eric: Was this original feature request for more things than just the target directory? How do we consolidate these issues?
- Ed: We might not be able to self-ignore all the VCS that cargo new supports. And we'd possibly run into inconsistent behaviour between these VCSs
- Josh: The self-ignoring thing is cute but doesn't seem it has a fundamental advantage over what we're doing. Plus, if we emit the file once, that gives people the chance of editing it as they see fit.
- Eric: If you're creating multiple packages, those target directories don't get ignored
- Arlo: I had this while working on a repo that existed without Rust, I've added that in and it didn't generate .gitignore -- I had to do that manually
- Josh: What is the scenario where the target directory isn't in the top-level directory and it's not inside
- Arlo: If you run `cargo new` in an existing git repository, you won't have the `.gitignore` file created
- Josh: I see. That seems reasonable for us to create.
- Arlo: I think we can detect we're in a git repository and automatically create it when you do cargo new
- Josh: When we're in a git repository and not in the workspace. We shouldn't do this while we're in a workspace.
- Jacob: We should continue to fix problems, but we should communicate that cargo new isn't something for everyone. It's not customizable.
- Eric: I propose to move this to needs design. There's desire to have something better, multiple competing usecases and desires.
- Ed: Does it sound like people want the self-ignoring issue to be closed?
- Weihang: There may be tools that only look at top-level .gitignore not a subdirectory.
- Ed: We should probably design for correct handling of gitignore rather than work around incorrect implementations
## 2025-11-25
Out: Dongpo
- New RFC: Target Stages, an improvement of the incremental system https://github.com/rust-lang/rfcs/pull/3881
- Ed: I read it, it seemed to lack details to be meaningful. It was trying to reuse build artifacts between build and check
- Eric: They wanted to split the compiler up to have more stop points. To make it more fine-grained and compatible. But the RFC is light on details.
- Josh: This is the thing a talk was given at RustChinaConf by the same person. The main use case is cargo check & clippy & build getting to a point where things get reused if possible. The easier part is having `check` do some work that `build` can reuse. And the harder bit would be `clippy` doing work `build` could reuse
- Ed: I've already provided some feedback
- Eric: I'd like to see the compiler team weigh in more heavily before we do. It seems it's more the compiler's responsibility.
- Josh: Yeah, if the compiler is satisfied then we can make use of it.
- Ed: It's not that automatic. For example figuring out how to handle different optimizations. There are fundamental design questions on "do we even want this" and "what do we use by committing to this"
- FCP Reminders:
- build-std: context https://github.com/rust-lang/rfcs/pull/3873
- clean: Add --workspace support
https://github.com/rust-lang/cargo/pull/16263#issuecomment-3534536134
- feat: stabilize -Zconfig-include https://github.com/rust-lang/cargo/pull/16284#issuecomment-3563644951
- Discussion about meeting minutes
- We're running out of space in the free plan and need to clean up notes periodically
- We discussed getting a non-free plan
- We've discussed moving minutes to github like e.g. Lang, FLS, Content, etc. teams do
- Tomas can do this
- The Cargo repo isn't a good candidate, but we could create a rust-lang/cargo-team repo for this and other things
- We'll come back to the topic at some point
- Josh: feedback from polars developers about synchronizing features across crates in a workspace. Originally asked for "workspace features". Talked to them about their needs, and it sounds like global features might work for them, if we support global boolean features with the usual "wired-or" on-if-anyone-wants-it behavior.
- https://github.com/rust-lang/cargo/issues/1555
- https://github.com/rust-lang/cargo/issues/9094
- https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618
- Josh: If you have enough of a crate hierarchy that not a lot of the things are depended on the top-level crate, they have to be careful about plumbing every feature they have. Sometimes they forget and you end up with two different crates that touch the same enum, but they don't match because they don't have the same feature enabled
- Josh: It seems what they want is the "global features" mechanism. If they have one "polars-features" crate that define features across all of polars that all crates will depend on and take features from
- Ed: I don't think global features fits. The fundamental design is trying to avoid unification.
- Josh: I thought global features did want unification. Except you can't reconcile non-boolean features.
- Ed: If you want features with different types: enums, integers etc. You can't unify this and that's what global features are about. Defining features on the leaf rather than a root.
- Ed: I think we need to dig into this problem ourselves and see how we could create an abstraction / helper for scenarios like this. One thing we have is automatically enabling features when we have features enabled, etc.
- Josh: That's why I brought up global features. They seem to have 2 things: (1) features with exclusive enum types etc. (2) exported features -- this crate defines a feature and a crate depends on that crate can check whether the first crate's feature is set.
- Josh: It seems they want the export behaviour. Everyone can depend on polars-features and check whether the features there are set.
- Ed: In the design these two things are building on each other. We'd have to add this on top of global features.
- Jacob: And they touch on each other -- how do you find out whether a feature ??
- Josh: You can imagine having `export=true` or `pub=true` on something and so that can then be set and read. gitoxide has the same request. They see what polars is doing and they find it not ideal.
- Ed: This would help with proc macros. As we've seen with Diesel, features on the proc macro can be different than the code they generate.
- Josh: Because proc macro generates code that runs in the context of the crate, it would be great if it could look at the features of the crate they're called from (perhaps even via `$crate`).
- Jacob: We'll have to be careful about what `cfg` syntax we allow for specifying dependencies.
- Ed: One of the challenges is on the dependency side. How do we e.g. coordinate enabling bigint across the entire stack. How do we get that dependency enabled in all the right places. We ran into problems with this before.
- Josh: This gets hard when you use a global feature in Cargo.toml. But if you can use this cfg in your Rust code, that can't easily create cycles in the dependencies.
- eric: Noticed they have 154 features!
- epage: common perma [`S-triage`](https://github.com/rust-lang/cargo/issues/?q=is%3Aissue%20state%3Aopen%20label%3AS-triage) issues
- https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Issues.20with.20common.20symptons.20with.20many.20root.20causes/near/554498352
- rebuild-detection
- network
- crate-types
- OS related stuff
- Alternatives to handle some of these?
- Open a GitHub Discussions. Announcement category that doesn't allow new posts. Rebuild detection issue would be open for people to report their issue, and then if it is something real we can promote it to an issue.
- weihang: Better way to fix this, GitHub support threading.
- ed: Often in perpetual needs-info state.
- ed: Provide a way (documentation) for a user to step through their problem. For example, don't throw away the `target` directory. "Here's what we need from you to move this forward."
- jacob: Could add issue templates for these categories.
- weihang: Can you convert a comment to an issue?
- ed: Just do it manually.
- weihang: The challenge is some people just comment "hey, I had this problem too", but we're unable to get more information beyond that.
- jacob: If we've asked for reproduction, the comment could say that without more information by $date, we will close.
- ed: Was hoping that users could add to the existing discussion, and not just a me-too.
- ed: Regarding closing, some of these may be real problems, they trickle in different ways, if they were all closed we wouldn't be able to see the patterns for the root clause. Also feels calloused to just close as not real.
- ed: Was using S-needs-info on some, and we can track when that was added.
- eric: S-needs-info was the mechanism I used in the past, and the intent was to periodically close old ones.
- eric: I assume the documentation for rebuild detection needs more work. Also hard to find.
- eric: User reports are helpful, but not directly actionable. Not sure if those should be closed.
- ed: Meta issues are a good way to collect those.
- Eric: Checking in on status of recent regression: https://github.com/rust-lang/cargo/issues/16297
- ed: Looking at it
- epage: style of config-include
- should people think of it primary as array-of-tables or inline table
- https://github.com/rust-lang/cargo/pull/16284#discussion_r2556973764
- ed: Treating inline-arrays vs array-of-tables slightly differently. If doing array-of-tables, always focus on that, and not shortcuts, to focus people on that syntax. Top-level keys is a confusing thing for users (because it has to be before the table). That favors array-of-tables. The favor for an inline-array is that `include` is a very special key, like includes in C++ change how the file is processed.
- shortcuts could be array of strings, or just a string
- ed: Would prefer to just have arrays, and drop the string. Question is, do we also have array-of-strings shortcut?
- eric: You can't control whether it's an array-of-tables or inline-array-of-tables, right?
- ed: Yes. This would be more about how we think about it, and how we document it.
- ed: The dependencies table is plural (enumerating the things below it). But with `[[bin]]` is singular, because this is an individual bin unit.
- weihang: If the include adds more fields, then the user will probably just use array-of-tables instead of inline.
- ed: Some people put a good number of things in a dependency table, so I'm not sure what people will do with that.
- ed: Adding shortcuts later, but it doesn't buy much since we could just emphasize in the documentation.
- jacob: What was said about the position in the file?
- ed: When you use `include = [...]` it has to be at the top. With `[[include]]` it can be anyhwere.
- jacob: The position seems like it could communicate the precedence.
- jacob: Could there be a lint?
- ed: Could be a style guide for config.
- jacob: Just thinking if someone shoots themself in the foot.
- ed: Yea, I lean towards inline-array due to that.
- weihang: So do we remove the shorthands?
- ed: The string-only probably should be removed, but the array of strings seems ok.
- eric: Agree with what was just discussed. Bare string seems a little confusing. And docs/style-guide at the top makes sense.
- weihang: Will remove the string shorthand, and update the documentation.
## 2025-11-18
- FCP Reminders:
- build-std context: https://github.com/rust-lang/rfcs/pull/3873
- clean: Add --workspace support: https://github.com/rust-lang/cargo/pull/16263
- ehuss: force mtime https://github.com/rust-lang/cargo/pull/16273
- Beta backport
- Compiler support?
- Eric: sounds like it hasn't gotten any testing in nightly so far.
- Ed: I think Weihang is interested in speeding up the backport as it affects rust-lang/rust developers
- Weihang: Since it happens since 1.90 maybe it's not that big a deal.
- Eric: I've seen certain sys-crates recompiling unexpectedly.
- Ed: Just checking about the option of ddisabling incremental compilation in beta. We've done that in the past.
- Eric: Weihang have you heard about anyone?
- Weihang: I think they prioritised the issue but I don't know when they'll move it forward
- https://github.com/rust-lang/rust/issues/148948
- Eric: Can we escalate it to say this is really important?
- Scott: Asking on the compiler team for whom to ask might be good.
- Eric: Apiraino might be good to escalate
- Scott: I'd rather have the rustc fix than the cargo fix. This feels like a Rust change that Cargo has to handle rather than a Cargo change.
- Jacob: Wouldn't this also break anyone using `make` with rustc? This is a rustc bug not cargo bug.
- Scott: it would break any mtime-based build system
- Eric: Weihang do you want to try escalate it?
- Weihang: I can try that
- Eric: I think the fix in rustc will look almost exactly the same as you did in cargo
- whlo: `-Zconfig-include` stabilization
- `config-include`: https://github.com/rust-lang/cargo/issues/7723
- https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Policy.20of.20continuing.20an.20old.20FCP.20.28cargo.237723.29/
- Are we OK with the new syntax?
- Eric: we had an FCP ~2 years ago and one of my concerns was the syntax. Weihang updated the syntax and I'm fine with it. But if I resolve my concern, it'll immediately go into FCP. Since it's old, I want to check: are we okay with the syntax? Do we restart the proposal?
- Ed: I think it'd be great to restart so we can get familiar with it again
- Scott: Weihang proposed new syntax 2 weeks ago https://github.com/rust-lang/cargo/issues/7723#issuecomment-3478332059
- Ed: There are people who want cargo.toml file who want it to paper over issues that aren't available. We can create a convention around including another file. Do we want that or add support for e.g. cargo.user.toml file. And cargo new would add an ignore for that. By us making a new file, most people would commit it. That would encourage this local vs. set up. If we stabilize config-include, people might be able to start doing that and conflict with user-created files.
- Scott: It could use config-include internally to make it work. Having a users one seems fine. In cases where projects have a lot of xtasks it would be useful. It makes linting configs potentially easier.
- Weihang: should we prepend or append that config?
- Ed: I'd say local has higher precedent over committed.
- Weihang: In the repo they may have a lot of different local files, we might need to decide what to do
- Ed: I'd need to see an example of this
- Weihang: So we're proposing to cancel an FCP and open a new one?
- Ed: What are other people's vibe checks?
- Eric: I'm fine with the current implementation.
- Ed: In terms of the built-in local.toml?
- Eric: Are you concerned about the name having colisions?
- Ed: Right now .cargo isn't really use. There's potential for us having conflicts. The reason I think this could be useful to consider generally, instead of every project having to out into a local config, everyone would have access to a local config. Difference between built-in or an explicit include.
- Weihang: We could create a convention instead of built-in
- Ed: We can encourage convention, but that means projects need to opt-into it
- (epage) Disabling colored output requires convoluted `cargo test --color=never -- --color=never` incantation: https://github.com/rust-lang/cargo/issues/1983
- Ed: this will effect our testing deveex. When you pass in `--quiet` in cargo, we notice that and use the quiet flag on. We could do the same for `--color` but if we're passing `--color` and the user passes `--color` that would be a user error
- Ed: How much compatibility do we provide in terms of flags we pass to the test harness? We're going to have to figure something about this before we start supporting cases like this.
- Ed: I hope when we stabilize json output, we'll pass json format to the test harness and the user may be passing their own format. They may want to pass color always but we're stripping it off.
- Jacob: This sounds like semver hazard. I'd rather see more happen all at once. When people are complaining, we can say we've made this change, it's painful but hopefully it's the last time we'll break you.
- Ed: I hope color is not going to be a big deal. If we start supporting different harness tiers. We could make the color change on an edition boundary.
- Weihang: What if we start parsing libtest CI flag
- Ed: We'll have build.jobs adding our test.jobs and our flags will affect both so we'll be passing that as well.
- Ed: I'm pulling out libtest general parsing into a library. As a safety net, we could say that if they pass any arguments to us, we'll turn off any automatic features. But then you could pass --color and a specific test and `--color` being ignored
- Eric: I see you mention the idea of havigv the last CLI flag win
- Ed: That will work for some of these cases. But not for the format flag. If they start overriding json messages, that will throw off cargo's reading of the messages
- Eric: The compiler team had a proposal to have the "last flag wins" behavior
- Ed: I considered that for Clap, but having something you can pass once into being able to pass in multiple times becomes a breaking change
- (ehuss): mTLS: https://github.com/rust-lang/cargo/pull/16260
- Is this something we want to support?
- Eric: Someone wants to add mTLS support into Cargo. Is this something we want to do in a first place?
- Eric: it's mutual tls. Normally tls only does auth one-way. When you connect to example.com you know who example.com is but they don't know who you are. This makes it bidirectional. The user wants to add that support here.
- Weihang: Could we just expose all the curl options to the user?
- Ed: how much do we want to support curl vs. possibly moving to another option?
- Jacob: How does this fit with our authoentication story? It seems like if you have a server setup that on any interaction requires mtls, should we provide other forms of interaction? We'll need to think about the security.
- Eric: Do people think this will require an RFC. I was thinking it maybe could. It requires a broad interaction.
- Ed: That may be a good thing. Pull in people with different usecases. Get input from potential users and security stuff.
- Jacob: I think Josh had opinions about this. I wonder if Weihang could find Dan who did security upstream.
- Eric: They theis person wants to do it is to have a single certificate used for all network traffic. That doesn't seem right to me. You can be connected to different server, do you want to pass the same certificate to different servers?
- Jacob: You need an option ot try passing a single certificate for all the services. But you also need to be able to specify a per-service cert.
- Eric: I'll go back to the user to let them know that this probably needs an RFC and that it's not necessarily on our radar in terms of prioirty.
- Jacob: It could be that the answer from the expert is "if you can do this, it's better security than anything else we could setup so you should look into supporting it"
-
- Should we rename the default branch to `main` to match rust-lang/rust
- Eric: I don't who added this?
- Jacob: In retrospect we should have done this when rust did.
- Weihang: It might be annoying when you're checking rustc and the branch is different and the module is broken.
- Weihang: Is there any other module that changed to `main` in rust-lang/rust? Maybe github will redirect it?
- Eric: The redirect is about the website not necessarily the repo checkout etc.
- Ed: I have no concerns about it. All my new stuff uses main but I've not updated my 30/40 repos that still use master.
- Weihang: to address the modules, maybe we could have `master` and `main` in tandem for a while and then remove `master`?
- Eric: I sawe pople asking about this recently and it not being feasible
- Ed: Scott didn't add it and supports it. And Jacob said Rust Analyzer did it and there were no issues
- Eric: I don't remember if the submodule is going to be an issue
-
- epage: warning, not error, on `-Z` on stable?
- want to use new layout when available
- want to use new unicode when available
- Ed: There are new `-Z` flags to experiment with. But that requires it being on nightly, put it in a user-wide config. Could we do what we did for manifests where we could ignore them at least in config? Can we make it easier to have `-Z` enabled and only apply when teh conditions are right?
- Jacob: I'd CLI flags being ignored where it doesn't apply.
- Ed: It would give you a warning there's this unstable feature that's not being used
- Eric: I think the unstable feature flag is being ignored on stable
- Ed: Does it? I'll try that
- Scott: that sounds like a lint. Don't warn I'm using an unstable flag on stable.
- Ed: There's precedence for this. But there are questions of: if we do this on the CLI. Maybe we can be loose on which `-Z` we accept. Do we make it a hard error?
- Scott: It would have to be a warning.
- Ed: We have to keep the `-Z` for now.
- Ed: I'll double check if the `-Z` is ignored on Stable and come back to this.
- Scott: It sounds almost like setting `deny_warnings` on CI and complaint we broke you.
- Scott: I want to write a post about unicode.
- Eric: if you just show an unused variable in a single-file project
- Ed: The `-Z` flag is allowed on stable
## 2025-11-11
Out: weihang
- FCP Reminders
- CARGO_CFG_DEBUG_ASSERTIONS https://github.com/rust-lang/cargo/pull/16160#issuecomment-3458280776 Eh2406, Muscraft, arlosi
- cargo-tree long forms for --format variables
https://github.com/rust-lang/cargo/pull/16204#issuecomment-3486822168 Eh2406, arlosi, joshtriplett
- (nominated) Ability to configure cargo run configuration https://github.com/rust-lang/cargo/issues/8644
- Wants to be able to configure environment variables to set when using `cargo run`
- epage: I tagged this team on a bunch of items to get a vibe check. What direction do we want to go with this? Specific design? Reject?
- ehuss: This is moving cargo towards being a general build tool. We allow set environment variables but ont per command. I'm hesitant going down that road.
- Josh: I'd consider CLI options and env vars differently. Configuring CLI options being default for cargo run has a potentioal for confusion. You can always add cargo alias in your `.config/cargo.toml`. For environment variables, we already do this in places.
- epage: What if we made aliases per table so we can set alias-specific environment variables? We'd add the features to aliases to provided the customization we needed.
- ehuss: There are these two issues for the working directory and environment variables
- cwd: https://github.com/rust-lang/cargo/issues/13348
- environment variables: https://github.com/rust-lang/cargo/issues/12477
- Josh: Exactly. If you're building a bin foo, you could add a `cargo run-foo` to set environment variables, work directories, potentially test runners
- Scott: like this?
```rust
[alias]
build-man = { cmd = "run --package xtask-build-man --", env = ["MY_ENV"] }
```
- Josh: yes
- Jacob: that sounds complicated enough for an RFC
- scott: How do aliases merge?
- ed: they are currently strings, so overwrite
- Josh: I'd love to see us adding something like cargo xtask
- epage: There are some challenges with this. Sometimes you want to be able to reference a dependency and call into it and customize some flags on it. Git allows you to shell out -- by bundling bash on Windows. There's a project called "duckscript" which is a shell implemented in Rust. We could provide that if we want to support bash-like shell.
- Support shell scripts: https://github.com/rust-lang/cargo/issues/6575
- Josh: We could go that way. The reason why I suggested xtask is that it allows you to execute something in your repository.
- epage: xtask is a workaround for the fact that we can't execute dependencies
- epage: Should we note this needs RFC for expanding the alias table?
- ehuss: There are two other issues: one for env vars and one for current directory
- Josh: There's also another project building something bash compatible passing the entire bash test suite
- epage: There's also a difference between embedding a shell interpreter or something that uses the bash syntax
- epage: We could close this in favor of the other two issues and crosslink them. I wouldn't join the shell script with them though.
- ehuss: I agree.
- epage: I think they should be done as a single RFC.
- ehuss: Open question: do we want to support substitutions?
- Quick note re `I-cargo-nominated` (Josh)
- Josh: We had an issue in another team meating. It was a rust-lang/rust issue that needed Cargo team input. We didn't have a "nominated" issue for Cargo. I've added it now and mention it.
- Jacob: I think our `I-nominated` labels were restructured recently. Thank you for adding us back in the list.
- Josh: That was a couple of years ago, I believe; I added those I-(team)-nominated labels.
- (nominated) cargo clean --target-dir should check if the directory looks like a Cargo target directory before deleting it https://github.com/rust-lang/cargo/issues/9192
- ehuss: It's easy to accidentally destroy your entire home directory by setting this flag. The request is to put some guardrails on this. Josh, was there a specific suggestion on how to do that?
- Josh: One was making a long-term transition to move away from `--target-dir`. It's essentially "delete this directory" so we could make a transition plan to drop that option. The other option would be to check for things we expect in a cargo target directory and list an warning and stop. I'm in favor the second option initially.
- epage: I'm in favor of the latter idea. Don't we write the cargo cache dir tag conditionally?
- Josh: I think we're writing it out unconditionally.
- epage: we have a function called `create_dir_all_excluded_backup_atomic`
- if the directory already exists, we don't create it
- Josh: Technically it's possible to end up in that space, but that will just make sure we don't delete it
- epage: Should it be a warning (with no-op) or error?
- Josh: We should not delete it.
- epage: Originally you said warning.
- Josh: It should error out.
- epage: There is a slight compatibility risk but probably not an issue.
- Josh: The only way to know is trying it.
- epage: Would we only do this if you specify `--target-dir` or for all target dirs?
- Josh: I'd only do it if you specify it. Because at that point it's equivalent to `rm -rf`
- ehuss: There's multiple ways to set it: environment variable, configuration etc.
- Arlo: is the compatibility concern the worry?
- Josh: I'd prefer to always check, but if the person ended up with a directory where it's not specified not to cause issue
- epage: Alternative: if you specify on the CLI you error on that case. In all other cases we provide a FCW that we will error out on this in the future. Then we can based it off the feedback from the user.
- Josh: No objection.
- epage: There's a lot of people who go the configuration route for caching purposes, changing drives etc. I think if they'er manually configuring something they're more likely to create the directory manually.
- Jacob: We could screen test this -- shortly after a branch we could merge a PR that sets it and if people complain, we can change it to only be effective on env vars
- epage: We could also add a `--force` flag
- ehuss: `cargo-package` and `cargo-publish` don't create the cache tag. So there may be other commands like that.
- Josh: We want to get that fixed, but that's a good point.
- ehuss: Is there a preference here on which direction we want to go?
- Josh: I'd error out for every case other than just `cargo clean`. But I'd defer to anyone who knows what people's other workflows may be.
- epage: The highest risk one is the `--target-dir` flag -- there we can error out. With the other ones, there's still chances where people could be creating the directory manually. And our tools haven't been good about creating target dir.
- ehuss: Sounds to me like detecting the use of `target-dir` as the CLI flag and detecting the cache dir is not there, then error out. And we can add the rest later.
- epage: That sounds good.
- Josh: Sounds fine to me.
- ehuss: I'll write that up and create an issue for the other thing I found.
- (needs input) cargo publish --index bypasses package.publish restrictions https://github.com/rust-lang/cargo/issues/16231
- eric: IIRC, this was intentional (though I can't find discussion or tests). `--index` is a low-level flag that is intended to be used *without* configuration.
- weihang: should we document about this? I don't think we can change the behavior.
- [RFC 2141](https://github.com/rust-lang/rfcs/blob/master/text/2141-alternative-registries.md#publishing-to-another-registry-preventing-unwanted-publishes) might be related?
- epage: There was a discussion about registry names vs index URLs. And how index URLs don't map back to names inside cargo.
- Arlo: I think that was around configuring authenticated registries. We have to do a reverse lookup to find a registry by checking all of them.
- eric: For historical context, index flag is much older than registry. It was a very low-level flag. When we introduced custom registries, we added the `registries` table. My inclination is that index is not something we should encourage people to use.
- epage: Should we deprecate it and remove it from `--help`?
- eric: Good question. I don't know how people use it.
- Josh: When you pass `--index`, do we act as if whatever index is crates.io or a custom registry that's not crates.io?
- eric: The latter: it's not crates.io.
- Josh: If you have `publish=false` does it bypass?
- eric: If you set to `false`, it's an error.
- Josh: So it's primarily going to be used for private packages with private registries. Most are probably using the custom registriess now. But there will be slow adopters.
- Josh: What if we say if you pass `--index` we create a registry with a placeholder name (e.g. `custom`) and proceed as if that was the registry we're using. That would work fine unless we
- epage: If this is to opt in people using the command line registry
- Arlo: only if they're using this to bypass the restrictions
- Josh: exactly. If they wrote `publish=["specific-registry-name"]` you'd think they have an actual registry set up in which case they're using custom registries
- Eric: I want to ask the author what they need
- Josh: The author self-describes as a bug hunter for security holes. They likely found a security bypass
- epage: This is two corner cases tied together. Is it worth designing a whole system for doing this? We could warn about this.
- Josh: I'm not suggesting we designmuch of anything. Just: can we quickly check that publish contains a magical token if you're using `--index`
- epage: Sounds you were suggesting a special registry name we check against. Why don't we just warn about it. To get rid of the warning you set `publish=true`
- Josh: That's fine, but my suggestion was to turn the warning into an error at some point.
- Jacob: Let's open an issue and ask people to bring up if they'd be against changing this over an edition.
- epage: FCW
- Josh: Starting up with a warning if you use index, steering people towards a registry.
- Eric: So we'd add a warning if you use an index with a publish restriction.
- epage: And we can suggest publish=true or create a registry config
- (backlog) Make sure that all files have proper mode and line endings
- https://github.com/rust-lang/cargo/issues/6008
- When people publish from different machines, it can result in different `.crate` artifacts with different line endings. This disrupts `cargo vendor` because each time you vendor a dependency, it looks like the whole thing is changing.
- ehuss: Agree with Ed's comment, it's not clear what cargo could actually do here. Imposing normalization seems like it could lead to more problems.
- epage: This is for .crate files. What are safe modes to set? And how do we know we can safely convert line endings?
- Josh: Modes seem reasonable. It's annoying if you're doing development on Windows and everything looks executable
- Eric: how would cargo know when you publish from Windows?
- Josh: We could detect if something looks like a Windows executable (in which case we mark it as executable). Or we get the file modes from git because those are reliable.
- epage: For the people using git.
- Josh: Yes.
- Josh: We should separate the line endings. That seems much harder to solve. We could direct people to git which already has an ability to handle this.
- Josh: We could add an option to squelch all the executable bits. You really shouldn't have an executable in the result. There'd be the some crates that have shell scripts in it
- Josh: If we're on Windows and there's some way for us to detect we'er on a filesystem that has no concept of executable bits
- Scott: Could we use gitoxide to redo the line ending?
- epage: We have to have all the git style infrastructure for what's a file type etc.
- Scott: Could we make the executable bit a lint / error at publish time? If you do want a shell script you can just turn it off. For someone to turn it of they can set `cargo.toml`
- Josh: We could have a warning saying "pretty much every file is executable"
- Scott: You could start there and then make it configurable.
- Arlo: The issue was less Windows and more that they were using NTFS (they were on Linux at the time, accessing the FS). So it might just be an issue with having those filesystems from Linux
- Josh: That's a good point. When you mount FAT32 or NTFS, every file looks executable. That's harder to detect.
- epage: I'd be fine just closing this issue.
- Josh: Back to Scott's suggestion: we could just give you a cargo warning if you're doing package/publish and all the files in your crate are executable. The obvious case: your `*.rs` are executable.
- Scott: or your `Cargo.toml`.
- Josh: That's better: we can check whether `Cargo.toml` is executable and then we can tell you.
- Scott: It would makes sense to either make it configurable or making a separate lint.
- Josh: The reason `Cargo.toml` is the trivial case is that it covers you're on a weird filesystem. If you have *half* of the files in your crate on a different mounted filesystem (like FAT32), you probably know what you're doing.
- Josh: What are the blockers for the linting system to get it over the finish line?
- epage: We should add a checklist for the tracking issue.
- Scott: https://hackmd.io/km2MDywSTBeq8Dy_HXXwgw
- Scott: There are ideas on how we're doing groups (are we even doing groups?)
- epage: It's more of, there being a weird tension in our lint levels. The recomendation out of All Hands was we should lint like rustc: everything in Clippy but one level relaxed. If Clippy is deny, rustc is warn etc. But if you bring the lint group from clippy, do we have that stay warn and what lints do we put in that category?
- Eric: Do we want to move for this to a lint, does it need design?
## 2025-11-04
Out: arlosi, scott
- Tomas: Project Goals open hours
- Niko set up four meeting slots to [discuss anything project goals-related](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/2026.20plans/near/553456395)
- Two are today (2025-11-04), the other two on Thursday 2025-11-06
- He's also sent an email to all@ with some proposal
- If you have thoughts, feedback, anything to say about project goals, join one of the meetings: https://meet.jit.si/roll-over-beethoven
- New RFCs:
- build-std context: https://github.com/rust-lang/rfcs/pull/3873
- build-std: always: https://github.com/rust-lang/rfcs/pull/3874
- build-std: explicit dependencies: https://github.com/rust-lang/rfcs/pull/3875
- FCP reminder:
- Enable CARGO_CFG_DEBUG_ASSERTIONS in build scripts based on profile — https://github.com/rust-lang/cargo/pull/16160#issuecomment-3458280776
- eric: build-plan removal
- referencing https://github.com/rust-lang/cargo/issues/7614#issuecomment-3377367890, was there anyone that wanted to volunteer?
- epage: I can go ahead and do that.
- elldritch had a question at https://github.com/rust-lang/cargo/issues/7614#issuecomment-3377757657 about figuring out the OUT_DIR for a specific invocation. Difficult to answer without having a clear picture of what they are trying to do.
- Room: no one was aware of anything
- Josh: It might be sensible to tell them to drop by one of the Cargo Office Hours to talk about their usecase
- cargo -Zscript doesn't work for memfd created files anymore
- https://github.com/rust-lang/cargo/issues/16110
- Canonicalize strikes again.
- epage: We did a call to `cannocilaze`. It's generally banned in cargo codebase. We've added it to use the build-dir plumbing. This user is creating an in-memory FD and writing to that memory and executing that. And that doesn't work with `cannonicalize`.
- epage: Do we want to support this workflow?
- Josh: If there's a way to support executing from a file descriptor, then we should.
- epage: We need to make sure we test this so we don't break it again. We could solve this by doing `unwrap_or` with the original path on the `cannonicalize` call.
- Josh: Will we even have a regular path for that?
- epage: They have to pass a path to cargo. And they're passing `/proc/memfd`
- Weihang: Is cargo-script the only place that doesn't support memfd?
- epage: For a lot of other places you're operating on multiple files. What does it even mean there?
- Weihang: I was thinking of the unstable flag for lockfile path. By supporting this, we will support memfd for cargo-script, right?
- epage: Yeah. That's why we want to add tests.
- Jacob: Does the operating system have a direct way to say "I have a path but what is the unique ID for this file"?
- eric: Not that I'm aware of.
- eric: There's the `try_canonicalize` method but ... on unix that doesn't do anything.
- epage: user wide cache and hard links
- I had assumed we'd read from both the build-dir and build-cache
- ranger-ross is looking at using hardlinks
- Can't do cross-filesystem hardlinks
- Any other gotchas to be aware of?
- Any general sentiment that could shape the conversation?
- Josh: The filesystem thing doesn't seem to be a big deal.
- epage: If we just do a general "hardlink or copy", the copy cost would be greater than the cost of compiling. We should disable the build cache at that point.
- Josh: I think that depends on the crate.
- Josh: The other issue is the possibility of overwriting the hard link. If you touch the file in your build directory, it'll mess up your cache.
- epage: I was wondering about doing a reflink or hardlink call.
- Josh: Reflink is great but it's unfortunately not available on a lot of FSes.
- epage: It's now on the mac, windows and some linux distributions such as Fedora
- eric: What would go into the user-wide build cache?
- epage: build unit directories. Things that don't execute build scripts or don't depend on proc macro.
- eric: Why are we hardlinking at all? Why not create the files in the shared cache.
- epage: That was my original proposal. We probably don't want to build directly into the build cache because we'd have to hold a limited build lock. With doing that there's a risk of us changing mtimes. That's normally not an issue but I don't know how that interacts with build scripts. The other reason is pipelined builds: we have to use part of the build output while building.
- epage: The hardlink discussion came out of nowhere so I wanted a vibe check.
- Josh: ccache has an option for hardlinking files out of a cache. It has a short description and long warnings. All the warnings seem to be relevant to us. We should absolutely do reflink if it's supported by the way. Any time we would have copied, we should use a reflink.
- epage: Thanks for pointing that out. I'll pass that to ranger-ross.
- epage: I'll say that it might be a good starting point that we could prototype it later.
- Josh: If we were going to use hardlinks, we could `chmod` the file to be read-only.
- epage: I think chmod did come up in the conversation.
- eric: We did have that in the past.
- Weihand: build-script needs to copy it and by copying into out-dir it needs the permission to copy it. There should be a zulip conversation topic there.
- epage: Re locking: originally I didn't plan to do fine-grained locking. Either exclusive, shared or append lock. The problem with that was pipelining and mutable build units. We could treat the build-dir like the shared cache -- where we might use fine-grained locking for mutable build units and everything else is a shared cache. Another option is stop having mutable build units and GC them aggressively. If we created separate build units for source code changes that would cut down on rebuilding but it would use up a lot of space.
- epage: https://ccache.dev/manual/4.12.1.html
- epage: `cargo::copy=<source>:<relative dest>` build script directive for final artifacts
- https://github.com/rust-lang/cargo/issues/13663
- Proposal:
- Only run for root / selected packages to reduce collisions and suspicious things activities from dependencies
- Leverage https://github.com/rust-lang/cargo/issues/3544 (`cargo::metadata` without `package.links`) to tunnel up to root packages
- But then people may have "unused" deps that are used for the build script side effects. `lib = false` from artifact deps?
- Questions:
- Would we want a "copy" that existed in deps and how would we distinguish these?
- File or also dir?
- File to file or also file to dir, along with all the corner cases of `cp` (when to treat the dest as a file vs a dir)
- Josh: I kind of love this. Metadata is underused across Cargo. If we don't tie it to links, do we need another mechanism to make it unique?
- epage: We have a cargo_dep_NAME_toml env var.
- josh: That seems reasonable
- epage: This would be available to all the people using links.
- Jacob: What about transitive dependencies?
- epage: metadata is only available for root dependents.
- Josh: This would let us resurrect the RFC to provide build artifacts.
- https://github.com/rust-lang/rfcs/pull/3035
- eric: The completion files would be put in the artifact directory. What would happen with them?
- epage: the build script would write them to out-dir as normal. But it would also add a copy directive that would have the relative path to the package
- epage: It would reuse the existing metadata
- Josh: So this would reuse metadata and also add the copy directive? Sounds reasonable
- epage: Would we want a "copy" that existed in deps and how would we distinguish these? Does that affect the naming of this copy directive?
- Josh: I do think the propose name of "artifect" makes sense.
- epage: I liked the idea of the name being more explicit. That it's just "copy this to another directory".
- Josh: I also think it'd make sense to support this for deeper things in the tree. To provide an artifect to the top-level crate that it can then take it and do what it needs.
- epage: Something like an export mechanism that tells you what's available? How do you decide the layout within the artifact dir within the top-level export?
- Josh: I'd expect these things to have names and the name would have the name within the artefact dir in the top-level crate. If it's not a top-level crate, it would be a path to resolve this.
- epage: We're reflecting how the build organization is in the artifact directory. Right now say ripgrep just say "copy a couple extra files to target directory and zip it". With this it's requiring us to be able to say "put this here and everything will be ready for zip". Your proposal is making things more explicit.
- Josh: I'm suggesting cargo-artifact src relative-destination. For a binary crate the destination is "put this in this path". For a non-binary it's not copied but rather it's provided as an artifact you can do something with.
- epage: The relative path is the name?
- Josh: Yes, that's the key you can use to get to the file.
- epage: For src and dest both being file and src and dest being both dir, the semantics are clear. How do we handle semantics of file and directory. How much of the `cp` semantics should we carry over?
- Weihang: Would this push us away from the idea of reducing the use of build scripts?
- epage: For use case like clap complete, doing it in build script is a huge pain; you need to pull in just enough of your project to generate the completions. The people who are generating header files. This would be an alternative workflow for those people.
- Weihang: ??
- epage: For the most part build systems are trying to disable build scripts and do things themselves
- Josh: What you described Ed sounds like a perfect reason for completions being done in a post-build script. Because then the post-build script would run your binary to generate the completions.
- epage: ~~That sounds good to me~~ (to not using build scripts, not agreement to post-build scripts) but I'm not sure what the other usecases.
- Josh: If we introduce post-build-scripts, we should allow them to provide artifacts in addition to build-scripts providing artifacts.
- Josh: Ed, this seems like it could use some design and iteration. I'd be happy to chat and talk through design. I have some interest in doing this for particular workflows.
- Weihang: I've seen people using the `cargo::metadata` directive and they thought it was appendable and they set it a couple of times.
- epage: There's the issue of how do we deal with conflicts in this scheme. My hope with it all being managed in root, it's all under the end-user's control so they could deal with a conflict.
- eric: When the env vars are set for build scripts, dependencies can read them. If a build-dependency assumes a name and a user sets a different name, it won't find it. That's not under your control.
- epage: In this case you'll have to pass the name into the dependency to know what to read it from.
- (backlog) Support multiple license files
- https://github.com/rust-lang/cargo/issues/5933
- What does it legally mean to have multiple license files? How would a user interpret that to mean?
- Loosely related issues:
- https://github.com/rust-lang/cargo/issues/12053 — Add metadata to mark all license and copyright files to be shipped when redistributing packages
- https://github.com/rust-lang/cargo/issues/8537 — license-file without license seems ill-advised
- ehuss: I would agree with Ed's comment that integration with something like REUSE sounds good.
- Josh: We talked multiple times about making a license-file and license interact. Defining a token in SPDX statement you'd be able to distinguish e.g. AND vs OR.
- epage: I was trying to find the notes for that conversation. I was thinking it would solve it.
- Josh: I don't know whether we have notes for that. It's stalled on design. 1. how do we modify the directive to modify the key. 2. how do we set the keys so they don't conflict. 3. ??
- Weihang: I think the spdx crate support custom license.
- epage: There's also a "I'm MIT and Apache 2" and I want to say which license files should exist for any copyright notices to propagate along etc.
- Josh: Another part is how do we deal with license files for SPDX licenses.
- epage: If this is meant to use like REUSE, we should point people to that. If it's about pointing at the SPDX issue, we should close this issue in favour of that.
- Josh: The spdx crate has what we look like we need, but it points to a spec that 404s.
- eric: Should we mark this as `needs-design`?
- epage: We can do that but we should also copy the notes from the previous meeting.
- eric: I wonder if REUSE could support the file inclusion as well
- eric: There's an issue about what's the point of having a MIT file when it's always the license.
- epage: That license requires including the license notification along the source.
- epage: We should help people help out doing things directly. Make sure they don't end up doing violations by default.
- Josh: This seems like multiple different problems that we need to address and we should write them all down.
Sign in with Wallet
Connect another wallet