Cargo team meeting notes 2025 Q3.2

--- robots: noindex, nofollow tags: meetings --- # Cargo team meeting notes 2025 Q3 Part 2 ## 2025-09-30 Out: weihang - FCP Reminder: [Add target="host" meaning the current host](https://github.com/rust-lang/cargo/issues/13051#issuecomment-3312988872) - Eric: Ed you had some concerns? - epage: My initial concern was with the host name which be confusing. Weihang renamed it to "host-tuple" to make it clearer what it means. - Josh: Can you clarify when you're talking about the ambiguity? What might we confuse this with? - epage: there's compilation host mode and the cross-compilation for the host tuple. Weihang clarified this to make sure this is a substitute to the host triple mode, not the cross compiler mode. - Jacob: maybe we need target=unset or target=none? - epage: I feel like "unset", "default" don't communicate what's happening no their own. - Josh: Are we still more or less thinking compatibility-wise long-term we want to move to there not being difference between cross-compiling to host and not-cross-compiling to host? - epage: is there a way for us to do it? - Josh: There are ways we can introduce the compatibility mechanism. The fundamental issues are the paths within the target directory. If somenoe's running target/release/my-binary-name and expecting it to work, for that we could just symlink target/release to target/host-tuple/release or similar. This could either be solved by a symlink or writing a binary to two separate place. - Josh: Someone did show how to do more compatible symlinks on windows recently. - Arlo: that's what rustup uses I believe - Arlo: I agree. - Josh: I'm not trying to say we should prioritize it higher. I'm observing there is a path to solution for that one which suggests `--target=hosts` until we solve the problem. - Arlo: host-tuple doesn't make it more confusing to me. - epage: If we stabilize the hosts table in the config, we need to clarify that the hosts table doesn't apply to the host tuple. Is this aligned enough with where we going? - Josh: Seems part of the problem is: the current situation where we don't apply target applies to host. And when we try to apply a different meaning to host causes confusion. It doesn't seem like we'll be able to successfully remove all confusion. The people originally proposing this wanted a short alias. - epage: The people asking for a short alias are asking: can I always put this in the config? The convenience factor is the variability factor. host-tuple also parallels rustc's `print-host-tuple`. At least for me it provides some separation for the `host` table. It makes it easier for us to have these conversations in the future. If we name the placeholder to `host`, it would be more confusing. There's always going to be some confusion for the cross compilation, but we'll add to it if we have two things named `host` that meen different things. - Eric: does this sound good to everybody? [...] Sounds like a direction we can move in. - FCP Reminder: [feat(publish): read token from stdin](https://github.com/rust-lang/cargo/pull/16001#issuecomment-3328769505) - Eric: I had a minoc concern: it was implicitly reading from STDIN and I wasn't comfortable about that. I was asking if we could make it explicit. - epage: What if we deprecated this and require login/logout? - Josh: Do we already support reading from stdin or are we adding it? - epage: We have it for login but not for publish. - Josh: When cargo publish invokes things like cargo test, it doesn't hand the STDIN of its own to the tests, right? I'd assume we either inherit STDIN or provide /dev/null. If we're passing the token, we shouldn't be passing it to other programs - Arlo: I agree, this is worrying. - Josh: I'm not considered about malice here, it's more about something stupid happening like a test trying to read stdin that gets printed as a test message. - epage: "protecting against Murphy not Machiavelli" - Arlo: you do make a good point about the environment variables. - Josh: Exactly, we might want to consider unsetting that specific environment variable. - epage: Probably the safest way is to deprecate without providing an alternative. That will let people provide feedback and see what the usecases there are. - Eric: The more you say it the more I'm getting comfortable with cargo login. We can also check in with Weihang. - Arlo: I think cargo login and environment variable are good. - epage: I appreciate the author's initiative. - Arlo: Can we redirect them to just the deprecation path? - Josh: Are you suggesting they may be willing to do the work getting this deprecate? - epage: They are willing to deprecate it. - Eric: That sounds like a good plan to me. If we need to course correct within the next day or so, we can. - [Goals](https://rust-lang.github.io/rust-project-goals/2025h2/index.html#cargo-team) check-up - Eric: any thougts on how the goals are going? - epage: I'll be prototyping cargo test using the json output libtest will do. I'm prioritizing cargo script. But I have a general design on the test output. If people have thoughts on test UX and test APIs and functionality, talk to me. - Eric: The other one was `cargo-semver-checks`. It seems it'll be a large jump from here to getting it to Cargo. - epage: I've laid out at least a couple of basics: checking semver related things in `Cargo.toml`. But then there will be conversations around UX. I've not seen Predrag (the point of contac) about this much. He has to basically re-implement the name resolution. - Eric: It's a concerning project due to the scope. Predrag has been doing great stuff, but I also get the sense he's constantly stressed about funding. That's a difficult combination. - epage: That also worries me. If it's a one-man thing not built like Clippy, how will we bring this into the project. I'm not sure where to put this to help people know when they are making changes. E.g. marker traits being created without your knowledge that you only find out about when people get broken. - Eric: the other big issue that concerns me is the instability of the json output. - epage: Once it ships with the project, it should become more stable. - epage: I think Predrag is using the rustc version output. But tracking nightly and stable and beta and cargo could become diffucilt. - Eric: If they change the format, it will fail. - Jacob: I think cargo-semver-check doesn't support just the latest. - epage: It supports three latest stable. - Jacob: If it only supported one, figuring out how to break this deadlock would be problematic. But if it's supporting more, we can fix this. - epage: I think it's mainly an issue of friction for contributors that would go away if we had subtrees. - epage: https://github.com/rust-lang/cargo/issues/12870#issuecomment-3291110968 `script.rs --help` reports `script.exe` instead of `script.rs` - If we can't guarantee support for mucking with things to report `scrpt.rs` for all platforms, are we ok with being inconsistent or changing this over time? - epage: There are hacks we could do on our side because we have `CARGO_MANIFEST_PATH`. But this could get complicated. So people requested if cargo could override whether its current exe argv[0]. But that's not something every platform support. - Josh: Not all platforms support this. But also not all platforms supoprt shebangs at all. I suspect the platforms where people expect `argv[0]` to work are also the platforms that support shebangs. - epage: I think it's more that if you use a library like clap and you use `--help`, you'll see `foo.exe` in the usage line. So e.g. instead of `test.rs` you'd see `test-.exe`. - Josh: I'm suggesting we do this on the platforms we can and then have people bring up platforms where this doesn't work to see how to provide it. - Jacob: Two things here: what is the executable. And what is the script people thought they were running. Do I understand the problem directly? - epage: I think so. - Jacob: For context, what does Python/Ruby/other tools do? - epage: Python and Ruby are probably different because they're interpreted. More applicable would be things like dlang, etc. do. But those are less common. I think Python and Ruby do have argv[0] be the name of the program. - Arlo: The most common usecase for this is for tools like clap that say "I need to have the name of the command line". - epage: There's a separate conversation about re-executing. The main request is a UX thing. - Arlo: I'm talking about printing something the user that conceivable paste. - Josh: I was just digging into the possible answer to this and as farr as I can tell, people say you can call CreateProcess and pass in an lpCommandLine string and that's interpreted as `argv[0]`. - Arlo: Yeah, you're supposed to pass the program's name there but you can pass anything else. - Josh: We should ask a Windows expert. - epage: Do we want the argv[0] represent what the user would want to run or what the user would re-do programatically? - Arlo: or do we want to represent a third thing? - epage: For clap, how do I decide whether use the manifest path or the executable name? - epage: If you're not using cargo-script, it's supposed to represent the user file name (the name of the binary). It's meant to be adaptive. To do that it uses argv[0]. - Josh: Obviously we can pass what we want via a nonstandard environment variable. - Eric: I'm saying the environment variable already exist. - epage: But it's not clear when to use the environment variable vs. argv[0]. - Eric: Are there any other similar tools that aren not interpreter like Python and Ruby? - Eric: I think Josh earlier said just do a best-effort. - epage: If we start with a best-effort argv[0], it's easier for us to revert that and do the executable path if we decide to go the other way. - Arlo: I'm leaning towards it argv[0] being the rs path - epage: If we're mostly using it for CLI help, current_exe is not what we need to worry about. - Jacob: it makes sense for all platforms to have a way for getting both pieces of information. We should make sure they're both available and documented. - Eric: I feel if it's documented, that's probably good enough for most people. - epage: I'm leaning towards argv[0] being the script and current_exe being the actual exe as a best effort. - Josh: current_exe on windows is using git module file name - Eric: sounds like a good path forward. - epage: For unsupported manifest fields in scripts, we currently use a denylist. Should we use an allowlist? - Josh: we should arange so that when we add a new field to the manifest, when we haven't explicitly said it's allowed/denied in cargo script, cargo should fail a test - epage: how would you write a test? - Josh: It should not be possible to add a field to the manifest without specifying whether it is or isn't allowed in cargo script. - epage: sounds like you're suggestting we restructuring the toml package. That may work, but we need to look. - Josh: I see what you mean and I see how you got there. I'm imagining: is there some way we can put this in whatever metadata we already have on fields such that we catch this aoutomatically. - epage: We could move them closer together, then people could see that they need to update them in a lockstep. - Jacob: Seems a simple allowlist shouldn't be that much harder. You could build a hashmap with a boolean and treat the absence of the field as it crashing because we haven't decided whether this goes into cargo script. - epage: the pre-deserialization check is before the manifests. So we'd have to decide whether a field is allowed and we'd have to do a debug_assertion [...] That would be doable. - Josh: To answer the original question: it would probably be safer to move from a denylist to an allowlist. The worst case scenario for allow list is forgetting to update the list and showing an error message. The worst case for denylist is a field that's now suddenly stabilized. ## 2025-09-23 Out: jacob, epage, arlo (1/2) * FCP: https://github.com/rust-lang/cargo/issues/13051#issuecomment-3312988872 - weihang: It's instastable on beta right now. Do we want to add a -z option in case the FCP takes time? - Scott: we have about four weeks so we should have enough time - If it hits two weeks out, we'll want to revisit - I see epage has at least one concern out though - Dongpo: I looked at it last night, I didn't get epage's concern - Weihang: the host constant is different in cargo.toml target and crate - the host string for target is for target architecture - ehuss: Weihang, did you want to follow up on renaming it? - Weihang: we still need to addres the first concern - but renaming can address the second one - ehuss: Do you have any opinions about the first one? - Weihang: I don't know. I feel it should be fine, but - Scott: It's not as bad as `target`, it makes it harder to understand but it's not that bad - Weihang: You can just unset it and write down the concrete triple - ehuss: The concern is the directory layout, right? Because it separates the target and a host compilation and it has a different layout. - Personally I'm okay with it, but I understand. It's unfortunate we always had this split. - Weihang: It's unfortunate that you can't unset it - Scott: I thought we had that. - (backlog) https://github.com/rust-lang/cargo/issues/4841 — In windows, the program by cargo run called don't have JOB_OBJECT_LIMIT_BREAKAWAY_OK flag - (ehuss) Seams reasonable to me. - Scott: I think it's reasonable to have a third party thing not respect Cargo's `-j` flag. That's essentially what's controlling it right now? - ehuss: It's a bit different. We create these job objects to encapsulate processes. When we kill the process, we kill the whole chain. But there's no way for the process to break out of the job. The default of Windows is not to permit it and we just need to set the flag to permit it. - Scott: Can we set it for the final thing Cargo's running? I don't want to set it for e.g. build scripts. - ehuss: Yes. - Josh: Is this similar to a process group on unix/linux that's done as part of daemonizing? - ehuss: Not sure I know enough to answer the question well. It seems similar but more complicated than that. - Josh: Seems reasonable to allow this. It doesn't seem harmful in any way. - ehuss: With no objections we can approve that. - Weihang: should it be done in Cargo or job server? - ehuss: Cargo - (backlog) https://github.com/rust-lang/cargo/issues/4895 — Add cargo:rustc-dynamic-link-search for setting LD_LIBRARY_PATH during cargo run/cargo test - ehuss: we have rustc link search, that only allows you to use search paths in the out-dir - I'd have to see when this search but rust lib search does add this to the dlib path, but it only adds things that are in the out-dir - Ah, it is a request for dylib in the system - Weihang: If we set the dylib, it will break the isolation in the system - Josh: this seems like something for which we may end up with some weird compatibility issues - for example it's important to *not* set LB_LIBRARY_PATH to any system directories - checking this seems like a potential nightmare for us handling weird system configurations - if you're pointing to non-standard directories for running shared libraries, that should be handled by your executable - Weihang: and you can use pkg-config to search for libraries outside and have them automatically add it - Josh: That would be for compilation purposes, but this seems to be for runtime - Weihang: I think cargo also adds search paths for whatever was set in the build script so it's also applied to the runtime - Weihang: The other option is using the `[env]` table where they could set up `LD_LIBRARY_PATH`, but it doesn't support variable expansion - ehuss: Thoughts? I feel pretty uncomfortable with this but I don't to be in the way of people getting things done - Josh: The ask is having a build script to set this. The problem is that this is an end-user policy. The build-script doesn't know what that user policy is. We could support a lot of different options, but it seems like a gian pile of complexity. - We might consider trying to do a best-effort intention. Print an advisory message to say that we have a best guess to say that they may need to set the library paths for the compiled binary. - ehuss: That's a tricky part when using `cargo run` because it sets not just the library paths but also other environment variables that the binary may depend on and not run without. This is adding more to that and the binary will almost certainly not work without it. - ehuss: How about we kick this off to a "needs design" status. Ask someone to write a more concrete proposal that addresses the concerns raised here and then look at that proposal. - Weihang: That sounds more reasonable. We may also want more usecases for this. - ehuss: A few people put some usecases there, but more would definitely be better. It's also not clear to me how common this scenario is. - (backlog) https://github.com/rust-lang/cargo/issues/5305 - Add support for resource files - ehuss: They're asking for ability to have cargo build copy arbitrary files to the output - runs into: how much of a general-purpose build tool is Cargo? - Josh: This has come up with a number of different things that people wanted to do. And it seems the most general thing is a "post build script" - people want to include config files etc. - we could support a whole bunch of things and decide what we support or we could give people the ability to do what they want here - Scott: [epage](https://epage.github.io/blog/2023/08/are-we-gui-build-yet/) had a blog post about Rust install scripts. At the time his conclusion was: Cargo is not a general-purpose build tool, if you need that, you should use one. There's a lot of concerns about build scripts and their security. Adding another tool at the other end would add more issues. - Josh: Build scripts run on the dependencies. This is something you'd only do on the target you'd do for cargo install. - Josh: Thanks for linking to the post. epage mentioned that if we had artifact dependencies, this is just a build script. I like that idea. We'd still probably want a potential way to emit "include this additional file alongside cargo install" - Josh: If we had that and we had artifact dependencies, we wouldn't need new kind of scripting. - Dongpo: If we want to support this, we can also allow people copying a whole directory to the output - ehuss: Seems like it'd be reasonable to support - ehuss: I want to close this for something else (post-install scripts or something), does that make sense? - Arlo: Agreed. - Josh: When we've said Cargo to be a general-purpose build tool, we mean we don't want to support non-Rust things (go scripts, java etc.) But I agree that things directly adjunct to Rust (e.g. a Rust cli tool but we also install shell completion or man page) - Josh: I do think we should close this in favor of artifact dependencies. - Arlo: I like the idea of extending cargo install for the top-level package. It goes along with the idea of extending things for the top-level package. - Josh: The artifact dependencies are similar. For installing additional files with cargo install, there's a lot of design and discussion that needs to happen. That's not what's happening in this issue. - Arlo: Reading Ed's blog about things like MacOS's universal binaries. - Josh: We've effectively solved the MacOS universal binaries by waiting for so long that X86 is dying out on MacOS and they're going to deprecate and remove it. - Arlo: But the same thing could happen again. We should at least consider it for the design. - Josh: Sure. And it's a concern for Android as well. But that's the cargo-apk problem. - Arlo: Windows can also have this issue and they won't be ditching the x86 issues at the same time. - Josh: I'd be happy to put together a few comments and then close it. - (backlog) https://github.com/rust-lang/cargo/issues/5368 - Add the ability to open a specific module when running `cargo doc --open` - ehuss: You're working on some module and you open the documentation related to that module. I'm trying to think if this is something Cargo can do by itself... yeah it probably could. - Arlo: Based on my limited knowledge of rustdoc it feels like something that sholud be possible. - ehuss: In this usecase you're editing the source, editing the docs, don't you always have the documentation open and reload it? - Arlo: There's clearly some desire for it. But I don't understand why you can't navigate to it and refresh. - Scott: When I was doing annotate snippets to refresh it. - Tomas: The way I understand the request is they want an editor shortcut that would open a specific page without having to navigate away form code to the browser. Similar to having a shortcut that does 'cargo run' or that runs a spefific test you're working on. - ehuss: I don't know if there's a way to open a specific query in rustdoc. - ehuss: Sounds like you'd have to type out `--open --module` -- would Rust Analyzer do that for you? - Scott: Yeah, I think you'd have the tooling know you've got a module open and it would fill out that name for you - ehuss: If we're saying rust analyzer is responsible for running this command, Rust Analyzer would be responsible for opening the page to the correct page. - Scott: How does it know which page it knows to open? - Arlo: Does it make sense to provide this endpoint for non-Rust Analyzer and then have everyone use it? It would be nice to do it once correctly. - ehuss: Would having a live-reload help here? Instead of using `cargo doc --open`, you'd just use `cargo doc` and the page would reload - Weihang: Should we look for feedback from the Rust Doc and Rust Analyzer teams? - Arlo: Yeah, if we had their buy-in that'd be enough for me to accept it. ## 2025-09-16 Out: ehuss, tomas, arlo, dongpo - weihang: reproducibility when moving workspace - https://github.com/rust-lang/cargo/issues/13586 - https://github.com/rust-lang/cargo/pull/14953 - Do we prioritize path dependencies in lockstep with workspace or independent? - How does path-base affect this? - How does this affect what is shown? - Fingerprinting absolute path is safer (we move workspace, is it still pointing at same thing) - We still fingerprint the content - We get separate cache entries when the source id changes - Do we optimize for people with absolute or relative paths? This change would improve relative but break absolute. - epage: absolute is machine/os dependent, so less common - josh: but some companies do require it! - epage: but for mine, it was an anti-pattern we were moving away from - epage: for me, I never have non-member paths. Microsoft has it all the time. Where do we expect people to be in the middle? - Do we expand `~`? - epage: I doubt it - trim paths? - but not requiring it - Issue is focused on symbol name for reproducibility, not on rebuilding. - trim paths would be for fixing that - **That means we do have reproducibility issues when using trim paths and non-member path dependencies** - Put the design back onto them - Comment posted: https://github.com/rust-lang/cargo/issues/13586#issuecomment-3299052534 - (backlog) https://github.com/rust-lang/cargo/issues/4840 — Suppress missing description/repository/etc warnings when publishing to a custom registry - see also https://github.com/rust-lang/cargo/issues/4377 - epage pointed out user-controllable lints as an alternative. - (ehuss) this is tangled with the general problem of registry validation - scott: Can the repository tell us? - maybe in the index config? https://doc.rust-lang.org/cargo/reference/registry-index.html - include links for documentation? - josh: if linted ouside of publish, how do we know registry to publish to? - `publish = true` means "publish to any" which includes crates.io - https://github.com/rust-lang/cargo/issues/6153 - `publish = [names,registry]`, we check those - If we use config.json, you likely already have it - if you don't and we do this durign cargo build and `--offline` is set, then *shrug* - Reproducibility issue on when the lint fires - But this might bloat the file when its needed to be checked regularly - we have caching but CI with clean instance could be an issue - but if we move the lint to `check`, then we run it anyways - when to run lint? - today, publish - if `publish=false` is the default, then even `cargo check`/`cargo build` could give these lints if `publish = true`, so the feedback is more timely (e.g. before you push a tag) - for now, maybe turn off by default for non-crates? - cargo-safe-publish - https://blog.weiznich.de/blog/cargo-safe-publish/ - submodule being dirty part seems reasonable - asked them to create an issue and they don't want to talk to us - someone needs to create an issue - untracked files being dirty? - changed package - we could checksum before / after - besides security, could be a good sanity check in case something else affected it - when we tar, we do it directly to disk - publish also streams from disk - Their dry-run -> regular publish approach is racy ## 2025-09-09 - Build scripts slow on macOS due to SIP / developer tool execution policy. https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F/with/536245777 - https://github.com/rust-lang/cargo/pull/15908 - Discuss further, consider the messaging - epage: having it as a note and be comfortable with the wording I'd be fine - be great if we could turn off advice from the CLI rather than asking people to edit a config file - concept from git: it's not a lint, more of a message that can be useful, but can be turned off per message - Weihang: can it be a lint group? - we don't have linting for ?? - there are other things where advice tables came up - feels less like litnting and more like a granular verbosity control - ehuss: we can leave comments on the PR, the messaging needs a little bit more work - this doen't affect just Cargo, it affects everything you can type in the terminal - epage: you can't have a more granular configuration to control explicitly? - the messages sounds like there's a sentry for cargo so you can more narrowly scope it - we need to check the exact behaviour and make sure the message matches - epage: parallel fetch of git - https://github.com/rust-lang/cargo/issues/15934#issuecomment-3263588698 - Requires a `Sync` GlobalContext, so would https://github.com/rust-lang/cargo/issues/15676 - Progress bars might be wonky - Error handling is a concern (the original motivation given for it beign serial) - Their branch has more changes than I expected - epage: most of the benefits would be also gained by shallow clones - but then doing it parallel would also benefit challow clones - Weihang: isn't shallow clone blocked on github side? - epage: it's not blocked on github, it shouldn't be a problem - but we need to make sure everywhere we do git operations it works - but converting to a full clone from shallow can be expensive - Jacob: it's also not clear how much github cares anymore - we're no longer using it for index so it's not the primary way people interact with github now - epage: we may have to switch to OnceLock if the current tooling doesn't support nonSync - it shouldn't be too difficult and the performance hit shouldn't be noticeable - ehuss: sounds at least worth doing an experiment for - weihang: do we think the progress bar is a blocker for this? - downloading will have multiple progresses - epage: the idea is that the longest progress bar would be the one that's show - and they're using rayon rather than our pre-async asynrc architecture - weihanng: maybe showing a combination of the progresses of all the downloads - epage+ehuss: yep - epage: we could have them parallelize the manifest parsing first - that's a smaller milestone but at least it's motivating for `GlobalContext` - ehuss: makes sense to me - epage: color and annotate-snippets - I started to migrate some messages cargo's using to annotate-snippet - consistency with rustc - move the warnings to lints - our note color is now the same as our header color - right now the goal is to output the same colors as rustc and then open discussion about changing some of them - I'll be splitting the PRs, there's a lot of messages we'll want to do - ehuss: all that sounds good to me, I don't have any strong opinions - Weihang: we should have an error message writing style guide eventually - epage: there's rustc's styling guide - ehuss: Ed brought up a small summary of what your strategy was - it was good, I wanted to make sure was everyone here was aware - but the general gist was to match rustc and its style and that sounds reasonable to me - epage: at some point I'll be playing around for a replacement for anyhow that allows an error to allow better diagnostic annotation that can be integrated with annotate-snippets - I think having chains of "caused-by" is a terrible user experience - turning those into notes and snippets and other things to be more user friendly on how we format this - it's part of the overall direction of this annotate snippets thing I'm doing - Weihang: what about libcargo? - epage: programatic error messages are difficult, for a project of this size they're even more difficult - https://github.com/rust-lang/cargo/issues/10160 -- being able to match on specific errors. - epage: that sounds less about API usage and more about improving the quality of the error reports - ehuss: rustc uses this custom derive proc macro and then has these translatable diagnostic files - I found it difficult to translate that - there's a lot of cumbersome indirection - the translation efforts have officially been halted - we need to be careful about how complicated the programatic error handling can be - Weihang: where was the announcement of pausing localization effort? - ehuss: it was an MCP - epage: RFC owners? - is there any conversation to follow-up, where are we going with this? - ehuss: It should be clear to everyone that Cargo is responsible for decisions about the manifest format - but if they're blocking progress, that's not great - Jacob: that sounds like they should be CCd on the RFC rather than being added by the rustbot - Weihang: Do they want to check their box or just being kept in the loop? - ehuss: couple options - I could do a public message on the RFC pushing against the actuon and see how it goes - or I could go to one of their team meetings and have a sync discussion - Weihang: or onece we've resolved concern, we caund get them check their boxes - epage: They refuse to remove inactive members so they can't get their boxes checked - that's why they don't use FCPs - they hold synchronous meetings instead - Jacob: Can we change the bot that when there's a cargo RFC happening, it notifies their channel? - they wouldn't be voting but they'd be in the loop - (backlog) https://github.com/rust-lang/cargo/issues/4505 — Add option to set environment variables only for being run process - Previous attempt was rejected: https://github.com/rust-lang/cargo/pull/4557#issuecomment-334374427 - `[env]` was stabilized in 1.56 https://github.com/rust-lang/cargo/pull/9411. This can be used on the command-line, such as `cargo run --config env.MYVAR=\'abc\'`. Is that sufficient to close? - ehuss: you can't do everything, it doesn't set env vars for cargo itself, but it should handle the rest - epage: I think the main intention on the generated binary and nothing else - ehuss: since we now have a solution and the proposed idea was rejected in the past we go ahead and close it - epage: They'd need to put a case for why the env table isn't sufficient, in the meantime I'd be fine closing it - epage: just setting env variables is not sufficient -- you may need to clean them, choose which ones to inherit etc. - (backlog) https://github.com/rust-lang/cargo/issues/4663 — Automatically enable required-features - epage had some suggestions on how this could work, with "Add a `--required-features` flag" and "For `--bin`, `--example`, and `--test` flags, enable the required-features" - ehuss: any quick thoughts about this? - epage: those are the best options I could thitnk of that honor the needs of different users - ehuss: was there some reason not to do this? - epage: you had concerns around `--bin` because it doesn't honor the order of the operations - Weihang: maybe we can add another new option "per target" to the unstable features? - but that might hurt the performance of entire build time - ehuss: to move forward, how about we add "needs-design" and have people experiment with what epage proposed ## 2025-09-02 Cancelled due to rustconf.