Try   HackMD

Cargo team meeting notes

https://meet.jit.si/CargoTeamMeeting

Label issues or PRs with I-nominated-to-discuss to add them to the agenda.

FCP/Nominated/RFC Status Overview

2025-04-01

2025-03-25

  • eric: Check if anyone is interested in helping with blanket source replacement?
    • https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Possibility.20to.20replace.20any.20source.20in.20config.2Etoml
    • https://github.com/rust-lang/cargo/issues/11406
    • jacob: There was some related work on the git/sparse equivalence. There are some landmines here.
    • ed: Doesn't know how it would work with git, so that seems like that needs some work. But seems like there is merit. How do you break out of the proxy, where there is a mix (inclusion/exclusion rules). Could put on them for determining use cases. Reach out on the integration stream to find what requirements clients have.
    • jacob: Nuget (or some other) has something more extreme, where it is substituting networking at a low-level, and you can customize what you want to do. "Here's URL, give me a file." A low-level system could help avoiding missing things in the future.
    • weihang: Why can't implement outside of cargo? An http proxy should be able to handle any request.
    • eric: Will try to follow up with some questions and level set some expectations.
  • epage: review open questions on build.build-dir, see https://github.com/rust-lang/cargo/issues/14125
    • Should {workspace-path-hash} resolve symlinks in workspace manifest path first?
      • workspace -> actual_workspace
      • Should the hash be on symlink path or the actual path?
      • josh: What might be the use-cases for this?
        • ed: Not sure.
        • ed: There was an unrelated issue about being able to rearrange and keep compatibility.
      • ed: Leaning towards resolving the symlink.
      • ed: Two-way door, can change.
      • weihang: Lean towards resolving.
      • Conclusion: Sounds fine to resolve.
    • Should we expose this in cargo metadata? To look up an existing location with a hash, will require matching cargo versions directly.
      • ed: We already expose target_directory
      • eric: Use cases?
        • ed: If they want to delete it.
        • Other tools like cargo-sweep for cleaning it up.
        • Users who dig into it, such as getting build script final artifacts.
        • eric: Other things like assembly
      • ed: workspace hash could change between versions. You have to use the exact same version for cargo metadata than is used for the build. Things like sweep would need to know all the versions the user used.
        • GC tracking could record all the directories, and cargo metadata could convey all that information.
        • josh: Giving all of them seems like a mistake. Giving just for this version is fine, but of limited value. Hopefully make these sweeper tools obsolete.
        • ed: Postpone putting rust version in the hash until we have better cleaning support?
          • josh: Don't gratuitously include it unless there is a reason to do so.
          • ed: Meaning of the hash is unspecified, so can add the version at some time later.
      • Conclusion: Don't include version in hash for now, and we can add it later. Include path in cargo metadata.
    • Should we error on unknown template variables? Unmatched { / }? Allow {{ escaping?
      • This is modeled after the registry template. Simple substitution of only variables we know of. Drawback is adding new template variables in the future. Old versions will create literal directories with curly braces in it.
      • Solutions:
        • Resolve non-variable as what it evaluates to
        • Error if unknown variables
        • Warn.
          • Can allow mixing versions of cargo while using new variables.
      • Considering the semver requirements. Don't want to have to comment in/out things when switching versions.
      • josh: Can be problems with git bisect or using older versions. Error on unknown is safe default. At least tell people what you do to only apply to new cargo (set it unconditionally in the environment? wrapper scripts? how to downgrade the error?). Some solution (even if a workaround); tell them what we do when we want to run older cargo versions.
      • josh: Have a way to specify in config "here's a stanza of configuration options that only apply if you are version X or newer". That might help with situations like this.
      • ed: If we error, should it also error on unmatched curly brace.
      • ed: Does {{ mean a literal {.
        • Can add that in the future.
      • Conclusion: will error on these cases.
    • Josh: What will the new default be, once we change the default?
      • ed: Plan to eventually be {cargo-cache-home}/build/{workspace-manifest-hash}
      • josh: Wants .CACHEDIR.TAG in this.
  • ehuss: Consider renaming gc config table
    • ed: Concern Jane's work about telemetry, tracking of operations for why things happen. Logs with rotation, should that also be controlled? Does that fit under cache, or would that be in a separate log table?
      • eric: My thinking is that anything that gets dumped in the cache directory in the XDG sense would be wrapped up in this.
    • ed: cache.global could be confusing for different kinds of things (like target which isn't global).
    • ed: Fine with simple cache.auto-clean-frequency, and can address with more things in the future.
  • ehuss: Should we specify the naming convention for cargo targets to be kebab-case?
    • https://github.com/rust-lang/cargo/pull/14439
    • ed: Common pattern for binaries to kebab-case. Don't care about tests (it's internal). Would put that note in the docs for bin and example tables as a recommendation.
    • josh: This came up before, was the response we shouldn't dictate binaries?
      • ed: Was that related to cargo new?
      • josh: Agree dashes are conventional, but wide variety of tools that use underscores, and you want it to be compatible.
      • ed: Definitely not an error, but maybe not even an warning. Just a recommendation in the documentation could be soft enough to let people make the decision that best fits their need.
        • scott: Could be allow-by-default lint.
        • ed: Downside, already created a package, then add the lint, then add a binary for the lint to take effect.
    • josh: Fine to document convention, but current warning is more normative than I would expect. Added suggested rewording.
    • ed: Does this belong in project layout, or reference? Feels a little out of place.
      • josh: Can understand why it is in layout, since that is the documentation that is showing the typical naming layout.
  • weihanglo: [lints.cargo] towards stabilization?

2025-03-18

  • epage: meeting publicity?
    • Urgau reported that they felt unwelcome by our lack of it
    • Office hours are heavily advertised
      • This example wanted a more official response from the team?
    • josh: libs-api/libs are public when, but the meeting link must be requested. lang team is public (sometimes has random people join and listen). style is public (normally doesn't have anything). Just have to pay attention if we have to discuss anything private. But hasn't caused any trouble.
    • eric: doesn't remember any historical context. We used to use Google Meet and some other tool (Zoom?). jitsi feels a little easier to access.
      • Some people have some friction with jitsi, and things like captions are missing.
    • https://doc.crates.io/contrib/team.html#meetings
      • We say it is open, but require them to ask for the link.
      • eric: Don't have any opinion on whether the link itself is public.
      • jacob: Link is posted in the calendar.
    • ed: Contrib docs could link to the calendar. Or just in the docs itself.
      • josh: +1 to link to calendar
    • josh: If someone drops in to ask something, we give a minute or two to listen. If there is something on the agenda, and they show up, then we bump up the agenda. Otherwise, may give some indication that is something they want to talk about, but acknowledge there is a long agenda.
    • ed: Seems like we have capacity for drop-ins, but would be good for people to pre-suggest their topic.
      • josh: If you want to drop-in and listen, feel free. If you want to discuss something, recommend first discussing in office-hour, or nominated for the agenda.
      • Seems reasonable.
    • ed: Advertising before start of meeting.
      • eric: likes the idea, to feel inclusive and not invisible.
      • josh: Link to the docs, not directly to the invite.
      • ed: Yea, so you can see the expectations.
    • jacob: Why did the contributor feel turned off?
      • ed: It wasn't specific, just because it wasn't advertised, didn't feel like it was welcoming.
    • weihang: Could there be a single thread for it?
      • josh: Some have a separate team/meeting stream. Don't drown out real threads. However, making them separate makes them less visible.
      • ed: One thread, people can mute it if they want.
    • conclusion: ed will take care of contrib doc, eric will post on zulip at start of meetings.
    • eric: Finds it interesting in lang how TC uses a "fuel" system to determine the amount of energy for prioritizing agenda.
    • josh: Can calendar automation handle the post-to-zulip thing?
  • cargo fmt for a single file?
    • josh: Editors want to be able to format a single file, without necessarily formatting the whole project. They currently do this by invoking rustfmt directly, but that doesn't use the edition / style edition. Could we add an invocation for cargo fmt that formats a single file, and encourage editors to always use cargo fmt for that if they're in a Cargo project?
    • epage: https://github.com/rust-lang/rustfmt/pull/5071 is the PR (rustfmt folks like to keep a "central place" but are fine with it being a PR…)
    • epage: this was part of the motivation for the <target>.edition deprecation
    • josh:
      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →
    • josh: Is anyone enthusiastic to push it forward?
    • ed: Challenge mapping to the appropriate Cargo.toml file? May need heuristics.
    • ed: Mostly on Caleb deciding on the design, and finishing off the implementation.
    • josh: What edition am I, use cargo metadata to the edition in a directory.
      • ed: There are corner cases, like #[path] from one package to another. Overall, probably good to make the assumption of the parent Cargo.toml file. cargo metadata will give you that.
      • ed: The difficulty is that cargo doesn't know about files, just directories.
      • josh: For edge cases, probably not too much of a concern?
      • ed: Could have more sophisticated things like rustc detecting the mod tree to detect file hierarchy, but that also has problems with cfg and such.
    • josh: Add cargo fmt single-file support for future IDEs. Should present ones use cargo metadata from the directory of the file?
      • josh: What should IDEs be doing?
      • eric: There's also cargo locate-project
    • rustin: What is the consideration for cargo-script?
      • ed: That's in the notes sent to Caleb. Will also coordinate with rust-analyzer for figuring out how to handle scripts.
      • josh:
      • ed: cargo pkgid can also provide information about the local project.
    • ed: Probably not much more than we can do.
  • epage: review open questions on build.build-dir, see https://github.com/rust-lang/cargo/issues/14125
    • Unstable build.build-dir has templating like {workspace-root} and {workspace-manifest-path-hash}. Could do some call for testing.
    • It has everything, except final artifacts.
      • ed: Plan to have the target-dir doc page getting updated.
    • Look at some unresolved questions:
    • Bikeshed the name build-dir?
      • scott: Likes that better than work-dir.
        • josh: Also work-dir reminds of git, which is where the user works, rather than where the tools work.
      • ed: Was thinking the build directory gets used for non-build things like "package", but probably enough related to "build" to be ok.
    • CARGO_BUILD_DIR as a shortcut for CARGO_BUILD_BUILD_DIR
      • josh: For a user, should be setting in global config.toml. Probably not set in the environment, except maybe in CI, where a short env isn't important.
      • ed: Mostly thought the stutter looked weird.
      • jacob: Have an issue, if this bothers you, we can think about it.
      • ed: Just call for testing, and see if there is any feedback.
    • {workspace-manifest-path-hash}
      • name?
        • This is a mouthful. Maybe something much shorter.
        • {workspace-hash} or {hash}
        • arlo: With path in there, it makes it a little clearer that if you move the workspace, it will be a different hash.
        • josh: And just {hash} might be confusing about it hashing the build.
        • scott: Feels its ok to drop manifest.
        • josh: Could use {path-hash} if you really want it to be short.
          • josh: Could it be confusing when in a different directory than the workspace root?
        • ed: What approach would get feedback?
        • scott: Doesn't feel like the extra "workspace" seems too much.
        • conclusion: Will go with {workspace-path-hash}
      • What should it include? Should the hash include the cargo version?
        • jacob: Would be nice to have two versions of cargo not know about the format of each directory.
        • josh: Could have a more opaque {hash} or {path-hash}.
        • conclusion: No objections to including the cargo version.
    • josh: Why are dep-info files included in artifacts?
      • ed: Yes, intention is to support Makefile and other build tools.
      • josh: Can they access them outside of the final artifact directory?
      • ed: It is currently advertised as part of the outputs.
      • ed: Could make it an option to disable .d files. Some kind of transition strategy.
      • josh: We could do that over an edition, so that in the new edition they're not generated by default, and you have to opt into them.
      • ed: Or a better way of communicating that information (i.e. not Makefiles).

2025-03-11

  • Should a path dependency recursively search for its package (similar to how git dependencies work)? https://github.com/rust-lang/cargo/issues/13360

    • ehuss: Can this be resolved with just a better error message? (Seems like it still has risk of unbounded filesystem walks.)
    • rustin: The example from the issue: 
      ​​​​​​​​cargo build  
​​​​​​​​error: no matching package named `my_crate` found  
​​​​​​​​location searched: /path/to/repo
      A more helpful message could be: 
      ​​​​​​​​/path/to/repo is a Cargo workspace, but "path" sources do not search sub-packages.  
​​​​​​​​Try: my_crate = { path = "/path/to/repo/crates/my_crate" }
      • josh: Possibly subtle detail on that error suggestion: it needs to preserve the absolute/relative path the user provided. 
        ​​​​​​​​​​​​../repo is a Cargo workspace, but "path" sources do not search sub-packages.  
​​​​​​​​​​​​Try: my_crate = { path = "../repo/crates/my_crate" }
    • ed: Agree it would be good to improve the error message.
    • Jacob: Would be nice for git to be able to specify the directory.
      • And not necessarily couple that with the ability to recursively do a path.
    • ed: Could have conventional practices, like if the parent folder is the package name.
    • josh: If the primary difficulty is loading the manifest to find the one we want, checking in the lockfile, could cache in the lockfile the path. Load the lockfile, check the one path it identifies, proceed.
      • jacob: Could be a breaking change to change the location of the git repo. People who depend on you, their lockfile would change.
        • ed: That would already happen if looking for a new version. Would probably just fall back to searching.
    • arlo: Feels it is unfortunate that git does the recursive search.
    • josh: Thinks there is value to search (assuming it is fast with a Cargo.lock).
    • ed: Could be some complexities/details to deal with things like the relative path nature to the path.
    • rustin: What's the best error message we can give right now?
      • ed: The error shouldn't imply that it recursed. In the error case, it can do the slow search for the actual package.
      • scott: And can give a suggestion on what to add.
    • git performance issue: https://github.com/rust-lang/cargo/issues/14395
    • conclusion: Add better error, inconclusive on actually supporting recursive searching.

  • Add include and exclude information to cargo metadata: https://github.com/rust-lang/cargo/issues/13331

    • ehuss: Seems like cargo package --list is the right answer?
    • weihang: Had a branch for cargo package --list for json.
    • ed: Multiple packages, doesn't differentiate the packages. Plain text output. Uncertain final source file versus original (like Cargo.toml.orig or license, etc.).
    • JSON: https://github.com/rust-lang/cargo/issues/11666
    • conclusion: Closing in favor of 11666

  • Symlink-or-copy LICENSE / LICENSE-* in workspace root when creating new member: https://github.com/rust-lang/cargo/issues/13328

    • rustin:

      iirc we automatically move workspace.package.license-file into the package on publish, so we could skip this if that is set.

      Do we need to document it?

    • epage: can only have on license-file, https://github.com/rust-lang/cargo/issues/5933

    • epage: we warn if license and license-file are both present as license-file is meant for custom licenses, see https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields

    • josh: Some reasonable way to avoid symlinking when creating a new member (so there aren't 12 copies). Can it automatically include on publish? Like a license-copies field, or license-file could be a compound field.

    • epage: extra-files field? but where to copy it to

    • ehuss: problems with symlinks on Windows

    • ehuss: what if the user didn't intend it

      • josh: If you explicitly have workspace.package.license set, cargo new will automatically inherit it, so in a sense it is similar to that.

    • epage: user could edit it from there

    • josh: Combining license and license-file. Would like some field that maps custom license name or SPDX license name to a license file. Then let you define license using SPDX or the custom names you just defined. That field would then be listing all the license files, so if it's workspace-inherited, we could automatically include them on publish.

    • license-file improvements:

    • josh: Would it make sense to have a workspace.new-files that would automatically be copied into a new crate?

      • ed: Pass, as getting too close to templating.
      • josh: Valid.

    • conclusion: Ed will close, we weren't really conclusive, eric had concerns about symlinks on windows, but copies are also recognized to be bad, want to resolve the license vs license-file problem.

  • Error for cargo run --bin {name} should notice multiple packages have the same binary name: https://github.com/rust-lang/cargo/issues/13312

    • ehuss: Seems like the suggestion of updating the error message to say -p foo --bin pgrx_embed seems like the right option?
    • epage: did https://github.com/rust-lang/cargo/pull/15199 improve this?
    • conclusion: Follow up with improving the error message with the -p, we recently already did this elsewhere.

  • Automatic cargo fmt after cargo fix: https://github.com/rust-lang/cargo/issues/12608

    • ehuss: Would recommend keeping these separate (though understands that the cargo fix results can be very messy). There is just too much risk, particularly if a project is not using rustfmt.
    • arlo: Could check for rustfmt being clean before starting.
      • User asks for a config option so they don't need to specify the CLI flag.
    • epage: Keep using cargo fix and then pushing the changes as a PR and CI fails because of cargo fmt --check.
    • epage: put this in a config? fix.rustfmt
    • josh: If we have a config option, it doesn't need to be specific to cargo fmt, it could be "this project is rustfmt'd". There is general value for general metadata, so there could be other things.
    • josh: Alternative tiny solution: a message recommending cargo fmt after cargo fix makes any changes.
    • ed: This isn't so much a chaining of commands, this is specific for cargo fix which generates poorly formatted code, and this is specifically for repairing that.
    • Can this format just the snippet modified by rustfix?
      • josh: There is an unstable option to format a range of lines.
      • epage: expanding of lines seems like a blocker (if not there)
    • josh: if fmted = true is enabled, error if rustfmt dirty, like vcs dirty
      • eric: why not a warning instead of an error?
      • josh: Thinking of this just like dirty vcs option. Require --allow-dirty
    • arlo: Somewhat prefer to have format be separate, and have cargo fix generate formatted output.
    • josh: Wanting it to be more general than just fix, like things like cargo package or cargo publish could check.
    • josh: Anything that does the dirty check would also do similar rustfmt.
    • conclusion: We are interested in exploring the idea of being able to configure that rustfmt is being used. May need to solicit feedback on something like internals.

2025-03-04

  • FCP Reminder:

  • epage: build-std

    • This is damaging my calm
    • The document is a mess
    • Summarizing is piece meal and I keep having to push them to do so over and over again
    • Focus on features and not end user requirements
    • Jumps straight to summarizing selected solutions
    • We didn't sign up with the project goal to mentor people
    • josh: What, precisely, is it that you're looking for from the document and not getting? I read the entire Zulip thread, and I still don't know exactly what you want from the document, so I don't know how the authors are supposed to. Could we talk through some of your expectations, and then perhaps make sure someone else from the Cargo team is their primary point of contact so that you don't feel the need to be?
    • josh: Some answers to that: Make sure references to past efforts on build-std are clear and self-contained within the document. For instance, references to "numerous problems" with a previous approach should actually state what the problems were. Descriptions of the rust-src component and the dependency of build-std's dependency on the standard library structure need to have a self-contained description of the problem (e.g. a summary of https://github.com/rust-lang/wg-cargo-std-aware/issues/85).
    • Don't have a definition of "done" for the document. At least cover the alternatives, the requirements, why they aren't moving forward. Difficult to express concretely.
    • Hard requirements, versus eventual requirements, versus non-requirements.
    • Uses cases, requirements, user-facing designs considered.
    • eric: Trying to figure out better ways to collaborate, to make progress.
    • eric: …

  • --frozen is not equivalent to --locked --offline: https://github.com/rust-lang/cargo/issues/15239

    • ehuss: This seems like a bug?
    • eric will follow up with a comment.

  • Should cargo use git proxies for other http requests? https://github.com/rust-lang/cargo/issues/14952

    • Cargo uses the http.proxy git config for all http requests. However, for some users, this proxy may not be configured for general network requests like crates.io.
    • jacob: How do we change this without breaking behavior?
    • arlo: This seems wrong.
    • ed: Worry about breaking change.
    • rustin: In my usage, the proxy usually works for both types of traffic.
      • I only use system level proxy. But I would expect it to happen with gitconfig, too.
    • ed: Corporate would be difficult to get feedback on.
    • eric: Add a config option?
      • jacob: Hate to have that forever, but seems to be the only way to
      • weihang: Short-lived environment variable?
        • arlo: If there is an environment variable, why not just tell the user to set the proxy?
    • ed: Need a way to unset the proxy, like http.proxy=false, which would be a way to opt-out. Could have a warning if you don't specify a proxy, and there is a git proxy.
      • jacob: Could also have a configuration option http.proxy="use git configuration"
    • weihang: Should this be documented?
      • ed: May not want to document, have the warning be a deprecation.
    • eric: Could the warning just be shown when there is a network error?
      • ed: The consideration is whether or not this is a bug in cargo's behavior. To what degree do we consider it wrong. If we are neutral, then a warning may not be needed.
    • weihang: Can it retry 3 times, and then fall back to the proxy.
    • eric: I can write up a summary of different options (and what it does today), and we can just pick something. There might be some considerations around the implementation complexity.

  • Feature request: Expose LTO profile setting to build scripts: https://github.com/rust-lang/cargo/issues/15144

    • Background: The user doesn't actually directly use this information. It is trying to detect a false positive with the no-panic crate which attempts to enforce that a crate never panics, which can have some possibly bad interactions with LTO.
    • eric: Normally fine with exposing some profile options in build scripts, but the use case here is a little odd.
    • ed: Would like to be use-case driven, because this takes on a certain level of compatibility that we want to maintain.
    • arlo: Is using LTO in build scripts for C code also a potential use case?
      • eric: Seems to recall a discussion about this, but don't immediately see it.
    • What are the downsides?
      • ed: Potential compatibility concerns as options evolve.
        • Example originally true/false, then changed to a different form (strings). Not as much as an issue since we have already added strings, but could be sensitive to how it is lowered.
      • eric: There are some complexities because cargo doesn't use just one LTO setting in the graph, it depends on the crate type, the dependency tree, artifact dependencies, profile overrides (maybe in the future), etc. Getting C code to match is also tricky.
    • weihang: What about https://github.com/rust-lang/cargo/issues/5891 which is for DEBUG which is only true/false, and not an accurate reflection.
    • conclusion: Eric will close for now, mainly due to the complexity/compatibility concerns. This can always be reopened in the future if we have more compelling use cases.

2025-02-25

  • RFC Reminder:

  • Weihang: favor link search path from OUT_DIR over external paths

    • https://github.com/rust-lang/cargo/issues/15220
    • Scenario: Building dynamic library from build script (which is discouraged in Cargo doc)
      • If there is a previous -L /usr/lib from other dependency, the package's build script will first link system installed one, and the build would fail because the one from the system lacking newly added symbols.
      • static lib, while not common, might be affected as well
      • rlib is not affected. -L dependency= is always prioritized and we might not want to support out-of-band Rust dependency linking.
    • User proposal: Prioritize lib search path from OUT_DIR than external search path like /usr/lib.
      • Risk: dependency linking to system lib may start linking to vendored one
    • arlo: Where did the system path come from?
      • weihang: Another dependency
    • arlo: Concerns it could have some breakage.
    • scott: Could test this on nightly.
    • scott: Could it be related to the security issue in the past about search paths?
    • weihang: Or provide some config? Or just say you shouldn't do that?
    • ed: What about a new directive that prepends?
    • ed: As for discouraging dynamic libraries, depending on built ones would be similar with artifact dependencies, which allow dylibs for rust
    • There's also a consideration of the order between different libraries. They currently are in some order, not sure if it is sorted in some way.
    • Make this a config option?
      • arlo: Would prefer to not do that.
      • weihang: A possible scenario is where two dependencies link to the same thing, changing the order could swap that.
    • josh: Where is the system path coming from?
      • There are two separate packages, one is adding the system path, another is adding OUT_DIR.
    • conclusion: Will move ahead with the proposal.

  • epage: ConEmu taskbar progress naming

    • Care abouts
      • Easy discover for people wanting to change this behavior
      • Clear meaning when looking at a config or config docs
      • Consistency with wider community
        • ConEmu: "Set progress state on Windows 7 taskbar and ConEmu title"
        • Windows Terminal: "Taskbar", "Taskbar Progress"
        • systemd: "Windows Terminal progress indication"
        • ptyxis blog post: "progress state"
        • VTE: "progress indication" ("progress hint" describes how to interpret "progress value")
    • Names
      • term.progress.taskbar: original intent but terminal/OS specific
      • term.progress.<term|terminal> may seem redundant, may be confused with content inside terminal
      • term.progress.notification: another escape code exists for toaster pop ups which this sounds more like, rather than a passive indicator
      • term.progress.<ansi|osc|escapes|osc9_4> are fairly low level; hard to discover or understand from reading the config unless you know nitty gritty terminal details
      • term.progress.<terminal-ui|ui|gui|system>
        • system is generic but specific enough to indicate what it is doing.
      • term.progress.report may be confused with when
      • term.progress.integration
      • Discussion
        • Josh: What about term.progress.terminal-report or similar, to distinguish that it's "report via the terminal"?
        • Josh: If this is on-by-default, and the config mostly exists for people who really want to turn it off, does it need to have a user-friendly name?
          • not on-by-default but auto-detect
        • jacob: for users who don't know the mechanism, they'll not know how to find it anyways
        • arlo: If a unsupported terminal shows escape, then something that says something about escape could help someone find it.
        • jacob: Would be helpful for the docs to mention the terminology used by other tools/terminals.
        • josh: term.progress.term-integration?
    • ed: Leaning towards system or term-integration
      • system as it is telling my window manager to report something.
      • scott: Feels like system can take a little more thought about what it means or what it is doing.
    • jacob: Seems unlikely we'll pick something that is universally intuitive.
      • ed: some things can be very negative but yes, the incremental positive is minimal
    • strawpoll
      • term.progress.system
        • Eric: +0
        • Josh: -1
        • Ed: +1
        • Weihang: +0
        • Scott: +0
        • Arlo: +0
        • Jacob: abstain
      • term.progress.term-integration
        • Eric: +1
        • Josh: +1
        • Ed: +1
        • Weihang: +0
        • Scott: +1
        • Arlo: +1
        • Jacob: abstain
      • term.progress.escapes
        • Eric: +0
        • Josh: +1
        • Ed: -1
        • Weihang: -1
        • Scott: +0
        • Arlo: +1
        • Jacob: abstain
    • Conclusion, term-integration

  • ehuss: i686 linux openssl libatomic

    • https://github.com/rust-lang/cargo/issues/13546
    • Propose to require i686 users to install libatomic
    • This is required for us to update from OpenSSL 1 to 3, as built by clang.
    • It might be possible to remove this requirement in the future with other workarounds.
    • josh: If that isn't the preferred solution for i686 users, I'm sure that they can send us a patch for their preferred solution.
    • weihang: Do we know how many it would affect?
    • weihang: What does it mean for tier 1 to require this?
      • eric: Doesn't feel like we have any specific requirements, as we assume certain things are installed to some degree.
    • josh: zlib-rs for flate2? Do we need to use the system library?
      • eric: no complaints to add that to all-static feature
      • josh: Supports all platforms, but has assembly acceleration for some specific platforms.
    • Conclusion: Will move forward with updating, weihang will post an update.

2025-02-18

  • Rustin: Deleting crates deletes reverse dependencies: https://github.com/rust-lang/crates.io/issues/10538
    • The crates.io team believes that Cargo’s assumption of an immutable index is completely reasonable. We did not anticipate that cascading deletes in the database would cause the index to be overwritten when new releases are published. We should avoid such issues in the future.
    • The crates.io team proposed three solutions. For the specific solutions, please refer to the issue: https://github.com/rust-lang/crates.io/issues/10538. Regarding Solution 1, the crates.io team thinks it’s not very reasonable, so it’s not being considered. The currently feasible solutions are only Solution 2 and Solution 3.
    • Since the crates.io team wants to hear Cargo’s perspective on these two different solutions, we’ve decided to temporarily implement Solution 2, which prevents the deletion of any crate with reverse dependencies. This is to avoid further incorrect updates to the crates’ index. After the Cargo team finishes their discussion, we can decide which solution to adopt. Currently, the crates.io team does not have a clear preference between Solution 2 and Solution 3; both solutions are acceptable.
    • rustin: This is user policy. Admin can still delete malicious crates.
    • jacob: What is the plan if the deletion needs to happen promptly. What is the correct way for the database to be updated? Just deleting removes the knowledge of it existing.
    • ehuss: deletion and merkle trees?
      • jacob: probably not, just an update of the index file
      • arlo: but when the index file is completely deleted?
      • jacob: yes, we need to handle that
      • ehuss: doesn't that run counter to an audit log
      • jacob: there are multiple technologies, audit log is just one
      • jacob: tuf just says where it came from, not if the admin changed things
    • Scott: Can you delete a chain of dependencies in reverse order, is that ok?
      • We're uncertain about the implementation, but that sounds doable/reasonable.
      • Arlo: may want to explicitly state that it is allowed.
    • scott: This is index things only?
      • Yes
    • weihang: Is there a way to detect the deletions?
      • arlo: It would be nice to have an audit log to know.
    • scott: Could there be a cooldown to reuse?
      • jacob: Believes there is a 24-hour period before re-publishing to accommodate mirrors.
    • josh: Do you have information on how often non-public deletions (dmca, privacy, etc.)?
      • rustin: I don't have that information. Can maybe look at public Zulip channel to get a sense. Have stopped handling those requests, though.
      • josh: This is helpful for signing RFC. The frequency, and how old it is.
      • arlo: There is a db of crate deletions.
        • josh: Could get a query, we don't need the details.
      • rustin: Could ask the team for that info.
      • jacob: Would like to be more public about the deletions table in the future. Otherwise hard to differentiate between something broken, admins did something on purpose, or there is a malicious change.
      • Just the names of deleted crates is all we really need.
      • weihang: Found that people immediately squat after something is deleted.
      • jacob: If deleting for the purpose of switch hyphens/underscore, can make it difficult.
      • arlo: 24 hour cooldown helps
      • josh: An administrative rename instead of delete could be helpful for those use cases.
      • Scott: Could stagger the cooldown. 24 hours for the crate owner, and 48 hours for everyone else.
    • jacob: Propose to post a summary of our thoughts to the public issue.
      • conclusion: Will follow up on this path.
    • rustin: The third option would need some more work to help with error messages.
  • weihang: CARGO: https://github.com/rust-lang/cargo/issues/15099
    • Problems
    • https://github.com/rust-lang/cargo/pull/11285 fixed the first two, broke the third
    • Jacob: Is the solution three different environment variables with the different meanings?
      • ed: I don't think so, its instead a problem with how we source the information
    • eric: Can the caller just unset CARGO
      • They want to use the toolchain that they were called with.
      • ed: That is a potential solution, but users would need to know to do that.
      • scott: Could there be a CLI flag to set it?
        • They would need to know to do that.
        • scott: At least from a documentation standpoint, it makes it so you can point to dothat.
        • ed: bloat cli
    • ed: rustup could take care of this. It could clear CARGO if it points to a different thing.
    • ed: except this isn't just rustup that can run into this and then those other people run into it
    • ed: cargo script kicks off a deb pkg build
    • josh: weird build.rs
    • ed: Possible workaround, if cargo-the-bin sets a flag on the context of whether or not CARGO should be set. This could help cargo-lib users, but not the ld case. Could also check the current_exe is cargo{EXE_SUFFIX}. Or an in-between that does both.
      • jacob: Could that be a cargo feature, so that cargo-the-bin sets that feature.
      • ed: not much different than context
      • ed: requires making sure release process does this correct
      • scott: require telling others building cargo, like companies, distributions
    • conclusion: Ed will write up the proposed solution
      • weihang: Will help test with dynamic linker use case
  • epage: cargo package and Cargo.lock
    • https://github.com/rust-lang/cargo/issues/15059
      • Wants to package in any order.
    • https://github.com/rust-lang/cargo/issues/15151
      • Cyclical dev-dependency.
    • https://github.com/rust-lang/cargo/issues/15159
      • Also out-of-order packaging and cyclical dev-dependencies.
    • ed: More OK with a random flag for cargo package than cargo publish.
    • eric: How much resistance is there to adding a cargo package flag to skip whatever needs to be skipped?
      • ed: Is ok, want's to give more thought to it.
      • Specifically "don't generate Cargo.lock".
    • weihang: People use cargo package as a way to package the source files. They don't really want verification. It is a glorified tar, that grabs the correct files.
      • And also fixes up Cargo.toml and readme/license files.
    • jacob: Could there be lower-level commands, like "make crate file", to address the use cases?
      • ed: Probably doesn't feel like it is needed for just this one thing.
      • The different steps don't split up very nicely.
      • Might want more exploration for how these get split up
      • Plumbing changes might be far out.
    • ed: Would this help with workspace-package?
      • For weihang, it would help.
      • eric: Might not help with debian though, since they don't have a workspace?
      • Should check with them to better understand.
    • conclusion: Handing off to ed and weihang to think about this more, and to possibly come up with a proposal later.

2025-02-11

  • Allow manifest dependencies of same-workspace crates to use workspace = true
    https://github.com/rust-lang/cargo/issues/13453
    • Instead of using path = "../other-crate", use workspace so that it is easier to move things around.
    • Complicates manifest parsing because we need to load all manifests to load one manifest, requiring multi-phase parsing
    • If we don't implicitly add version, this will be limited in who it helps
      • Slightly more people if we allow workspace and version but workspace means "get the source from the workspace" and is odd to mix with a source (requires defining more semantics which may be iffy)
    • If we implicitly add version
    • ed: Leaning to close, and make it explicit the policy that you want.
    • scott: Thinking of members table being explicit to avoid the multi-phase. But the benefits are lost since you still need to specify things.
    • josh: Doesn't seem to buy a lot of usability. Tooling improvements could make it easier.
      • ed: cargo new could automatically add to the [workspace.dependencies] table. Then you could do foo.workspace = true.
      • scott: The user didn't want to have to update paths when moving packages around the workspace. But only rewriting in one place is not too bad.
    • weihang: Not fully understanding the use case. Are they moving packages frequently?
    • ed: Block the cargo new behavior on:
      • Weird issues around default-features.
      • Seeing breaking changes can be harder to reason about with workspace dependencies. cargo-semver-checks can help. Public dependencies would be helpful here.
      • If the path is made too smooth, people may not realize the caveats of using it.
      • scott: Could have a cargo fix that could update the workspace to move {path="..."} dependencies to the workspace, and default-features could be modified to avoid the bad behavior.
      • josh: Could have a policy for what is used for workspace dependencies, and have cargo fix enforce that policy ("everything in workspace" or "only … in workspace").
    • scott: Recognizes that this would be useful, but not a good way to do it.
      • Some kind of (third-party) tooling like cargo mv would move and update all the paths.
    • conclusion: Will close. Open a new issue about possibly adding the new behavior to cargo new (and possibly think about other tooling improvements for workspace management).
  • [rustdoc] Integration test documentation build failure
    https://github.com/rust-lang/cargo/issues/13427
    • cargo rustdoc --test ... is broken.
    • The reporter resolved their issue, as they moved the shared code out to a library. However, the issue remains that the --test and similar flags for cargo rustdoc don't work. Should we hide/deprecate these flags? Should we support them?
    • weihang: remove or deprecate?
    • josh: Could call out these flags specifically in the error that they aren't supported.
    • conclusion: Remove the flags that don't work to make it in sync with cargo doc, and possibly revisit the decision in the future if we want to make these flags actually functional.
  • ehuss: stabilize doctest xcompile
    • eric: Main question was whether or not this needs to be an opt-in, or if it is ok to just turn it on for everyone.
    • weihang: would this require stabilizing stuff in rustdoc
      • eric: yes, runtool CLI flag and langstring targets
    • weihang: If cargo took over responsibility of testing of doctests, wouldn't need to stabilize the CLI flag.
    • josh: If this ran by default without --target, that would be worth being more cautious and requiring an opt-in.
      • Number of people running cross-compiling testing is probably not very large.
      • Posting blog and tweet could help raise awareness.
    • ed: Nightly testing could see the fallout. Call for feedback could tell us how much of an issue it is.
    • ed: Re upgrade pain, when it affects transitive dependencies, that multiplies the likelihood, but something restricted to just a workspace limits that.
    • jacob: The weird team that does weird stuff..we'll hear from them. :D
    • eric: Will move forward with the plan to back out if we get too much feedback.
  • weihang: cargo package if workspace manifest / lockile is dirty, assume the package is dirty?
    • https://github.com/rust-lang/cargo/issues/14967
    • https://github.com/rust-lang/cargo/pull/15089 is a bit too complicated with too many git operations.
    • josh: "dirty" is a best effort to prevent mistakes, and is useful. Cargo.lock is maybe a little different? Nevermind, this makes sense to check for cargo package.
    • eric: Wondering if could check just workspace manifest?
    • ed: Leans towards just checking the whole repo or the workspace Cargo.toml or workspace.
    • jacob: Could compare what git thinks and what we would have just looked at the filesystem, and compare.
      • ed: Weihang implemented something like that, but it was a bit messy.
    • jacob: Thinks this has changed over time, could be helpful to know why things have changed.
    • weihang: Is Cargo.lock included?
      • ed: Sure.
      • weihang: On cargo package docs, could say is best effort, could potentially package things that are modified.
    • weihang: Checking workspace manifest sounds like a good first step.
    • conclusion: Will move forward with that, and expand/contract things later as we decide.
  • epage: gut check: phase out per-build-target editions in 2027?
    • help with
    • josh: Should steer people towards workspace, multiple packages. Warning could say it could solve with a workspace.
    • jacob: If I'm worried about a semantic change, can imagine wanting to roll out the edition change progressively. Like making sure the tests pass on the unchanged code.
      • ed: Can't set edition for unittests. Integration tests don't have the ability to set a default for all integration tests. They would have to list all of them in Cargo.toml which makes it an impediment to using it.
      • jacob: Could differentiate for long-term (don't do this) versus short-term (for just migrating).
      • josh: Doctests have the ability to use different editions. For integration tests, if people need this, would be nice to be able to say in the top-level file of the integration test which edition it is. Then, something like rustfmt doesn't need to know anything (just parsing whatever frontmatter to learn the edition). That said, not advocating this unless people actually need it.
      • josh: Setting the edition of specific tokens could help with mixed-edition macro_rules testing. But not sure if that'd solve all the problems people have that motivate edition-specific tests.
    • conclusion: No concerns about deprecating, eric will do a quick scan to see if anyone is actually using it.

2025-02-04

  • jacob: TUF
    • https://github.com/rust-lang/rfcs/pull/3724
    • https://github.com/rust-lang/rust-project-goals/pull/244
    • Had a meeting with Walter on Friday.
    • Looking to split up so individual teams are signing off on specific parts. Will have directed information for what the team needs to know. Project goal is to work towards consensus, with time boxing. Existence proofs of whether or not it is implementable.
    • Highlighted the lack of communication.
    • Possible MVP of rustup, and less weight on the research side of things.
    • Concerns around forcing a specific solution. Was trying to focus on the level of the problem. Willing to explore other solutions.
    • Difficult to maintain context on this complex project without consistent time spent on it.
    • The team could help with a formal/non-binding way of the performance characteristics we would like to see. If it is 2x network requests, or 0.5MB data, what is acceptable? And what is our headroom?
      • Concerns that this could be very expensive. They are working on compression, but still some uncertainties.
      • arlo: Also concerns if the network requests are dependent on one another or can go in parallel.
      • ed: Also concerns about world-location and network performance.
      • arlo: Mirror could be a performance benefit for some people.
      • scott: Would also want to keep an eye on hardware requirements, if it requires significant more processing to decompress and such.
    • ed: Milestones would help a lot with communication.
    • eric: Will do a review of the goal, and async work with the team to get it approved.
  • epage: --workspace --package non-existent, see https://github.com/rust-lang/cargo/issues/12978
    • any transition period for an error for this?
    • for programmatic cases, a warning will likely go unnoticed
    • for human cases, they can just respond to the error
    • ed: My opinion would be an error from the beginning.
    • arlo: Agree, seems like a CLI bug.
    • weihang: Conservative warning could be 1-2 release.
    • scott: Chance of doing this seems slim.
    • conclusion: Will make it an error.
  • cargo clippy and cargo clippy --fix --allow-dirty have different reports
    https://github.com/rust-lang/cargo/issues/13527
    • cargo check does --bins --lib by default. cargo fix does --all-targets by default. User is confused by this difference (which is further masked since clippy has --fix as a flag instead of a separate command).
    • This was intentionally changed as part of https://github.com/rust-lang/cargo/issues/5739. Which looks to be related to edition migration, and concern over "not everything was fixed". and not wanting people to have to understand this.
    • ed: Is there a reason cargo clippy --fix needs to do all targets?
      • eric: It just calls cargo fix, and it wouldn't know to pass --lib --bins or whatever correctly.
    • ed: Alternative cargo fix could fix this, because it is doing cargo check in a loop.
      • Clippy could do something similar.
    • scott: Can we change cargo fix to not use --all-targets by default?
      • weihang: Could be acceptable.
    • weihang: cargo check --fix could be a hidden flag for them.
      • ed: Downside of cargo clippy --fix is not as rich as cargo fix. How do other tools integrate it as well?
    • ed: Can we change the default set of targets affected by --edition?
      • scott: Seems good. Might be confusing for some, but try to document it to be noticeable.
    • ed: Although this could be a breaking change, since it is mostly an interactive command, may not expect this to impact people much.
      • eric: Doesn't feel the breaking issue is all that important, mostly just which approach is least confusing, and I don't have a strong opinion about this.
      • arlo: Any concerns about IDEs breaking with this?
    • weihang: Should we loop clippy team in? Would need to update docs about --all-targets.
    • Options:
      • Punt to clippy
      • Change cargo's defaults
        • Keep --all-targets with --edition
        • Uncertain how to investigate any concerns.
    • Good to loop clippy in for conversation.
    • weihang: Moving cargo clippy to a built-in command?
    • arlo: Uncertain about why --edition would imply --all-features, since there are other things like features and --target that you still need to deal with.
    • conclusion: Ed will work on changing the default, and discuss with the clippy team.
  • allow cargo --profile debug for simpler Makefiles
    https://github.com/rust-lang/cargo/issues/13495
    • Impact if we split dev / debug?
    • ed: Would likely want to defer until we figure out that split.
    • artifacts-dir could also be an alternate solution.
    • conclusion: ed will write up summary on issue.

2025-01-28

  • supported-targets RFC
    • epage: Close out the field name
    • epage: preferring required-targets to mirror required-features
    • scott: Over the name, thinking that consistency (regarding required) might be more confusing here.
      • jacob: Could be more specific (skip if name not in these targets).
      • ed: Also considering the semantics of the field.
      • ed: Another suggestion was allowed-targets
        • known-broken-targets
      • jacob: Is this about using this package, or depending on the package?
        • ed: A future is about error reporting if depending on the package.
    • eric: Is this RFC useful without lock file pruning?
      • ed: Has a usecase where a large workspace would be useful.
      • jacob: Two potential implementation strategies.
        • The hard one: Doesn't require this RFC. If I depend on "foo" on linux, foo's dependency on winapi wouldn't exist. This is hard because another edge on foo would, would get complicated. Just looking at cfg targets, not the new field (just using cfg target dependencies). The root's target's supported targets would propagate to all the dependencies. People would mostly be happy with that (dropping windows deps is a major one).
          • jacob: we could move forward with this without the RFC for transitive-only cfgs, just requires the user to put every dep behind target.cfg.dependencies
          • ed: Usually the workspace does not have a cfg.
        • The other one: Needs this RFC. We don't do logic how you get to a cfg target, and compare the target.cfg.dependencies to the root package's supported-targets.
          • Would miss out on cross-platform transitive deps behind a target.cfg.dependencies
          • A 70-90% solution that is trivial compared to an unsure of ability to get perfect solution
    • eric: can we filter with cfg. SAT solving seems very complex and would be very difficult to get it to be generally workable.
      • cfg(windows) vs cfg(target_family = "windows"): would it keep the dep or drop it?
      • original design was target-tuples
      • rfc author added cfg
      • compiler people asked for target-tuples to be removed
      • eric: enough feedback from vendoring could affect this
      • jacob: Another issue is if the set is closed. Adding new cfgs would break the enumeration (or would be a backwards-incomatible issue). This would change the resolution (the Cargo.lock).
        • ed: Also, if we try to iterate and improve the SAT solver, that would change resolution and cause Cargo.lock churn.
        • jacob: Similar to the match non or overly-exhaustive lint fires on new code because the underlying solver got smarter.
          • Concern that the SAT solver would have to be right the first time. Anytime we change it, would be a lockfile bump or breaking change?
        • ed: Could go back to supporting a list of target tuples.
    • eric: Wondering about two different potential meanings of this field. One is "ignore this in a workspace", and the other is "generate an error if a dependency isn't supported". Will that be confusing?
      • ed: How does required-features work with artifact dependencies? This would be a similar situation.
    • jacob: application and library developers have different needs
      • apps: use target-tuples
      • libraries: use cfg
    • jacob: is this rfc blocked on sat?
      • ehuss: if this RFC restricts things
      • ehuss: maybe be a limited set of cfg's, like go?, to make this possible
      • epage: we need to keep in mind existing user confusion over cfg's
      • jacob: the full solution would require it
      • epage: problem anyways? wouldn't we need to compare supported-targets between each other
      • jacob: mainly benefit from one side of the formula being simplified
      • epage: we'd need to work with T-compiler for any assumptions we make on cfg relationships
    • eric: Confused about how transitive dependency support of supported-targets works.
    • epage: avoid this with target-tuples
      • ehuss: over-specified
    • ed: For the vendoring use case, there could be a config file option that lists targets supported, and that would affect the lockfile.
    • eric: Clarification on why things are being stripped
      • ed: Error-reporting is future. Untested/unverified data seeded in crates.io. To make it more comfortable, we can start including it in the future once it has meaning.
      • ed: be explicit that this does not affect dependents at this time
    • ehuss: credential providers could benefit from it
    • weihang: Do these two features need to be paired together? cargo vendor could do something different.
      • ed: Every command has to deal with doing resolution, which would change Cargo.lock or break.
      • ed: could put it in a config
      • jacob: put a comment in lockfile that config was used so it shows up in diffs
      • ehuss: if something is published with this lockfile, then there will be unlocked deps
    • jacob: they did a lot of work and need to acknowledge. Most don't create the big picture. They put in so much work, we can't even tell where they started (rather than a "solution to my problem")

2025-01-21

  • FCP reminder
  • (ehuss) Confirm we are ok with changing config merge
    • https://github.com/rust-lang/cargo/pull/15066
    • Are we ok with the potential breaking change that arguments are no longer concatenated?
    • ed: Seems unlikely someone would intentionally try to figure out how to use this.
    • eric: I have not seen anyone do this, but really hard to survey.
    • jacob: Probably can't find out until on stable.
    • Jacob: How hard would it be to set it back to the old behavior for a version or two?
    • arlo: Painful. It could regress behavior.
    • Ed: Can we do a future compat warning that asks to contact us?
      • Might be difficult since config doesn't have access to the shell.
    • jacob: Recommend just do a breaking change.
      • arlo: agree
    • scott: agree with just moving forward.
    • Decision: Move forward, revert if complaints on nightly or beta. On stable we'll have bold info in the release notes.
  • Goal review
    • https://rust-lang.github.io/rust-project-goals/2025h1/index.html#cargo-team
    • libtest json should probably include cargo: https://rust-lang.github.io/rust-project-goals/2025h1/libtest-json.html
    • For the open owner ones,
    • Rust-for-linux
      • Uncertain what we are approving. Aren't they not using cargo?
        • build-std is what we are asked for
    • build-std
      • Biggest work, most unknown.
      • eric: looks like it is asking just for writing the RFC, which seems like a reasonable ask.
      • scott: Would be helpful to have a document describing the current state.
      • arlo: It says "It is intended that this MVP be sufficiently useful and complete that it could be stabilised."
    • crates.io mirroring / quorum-based verification
      • ed: discussion has been intimidating, hard to prioritize something abstract and niche, concerns of some of the problems that don't seem to have a clear solution. difficult to follow. Is there anything we can do about the index problem.
      • jacob: This scales levels of complexity. The overall architecture is tightly connected to the network requests. Hard to keep those high/low level concepts in the same picture.
      • jacob: Trying to invent it yourself, you'll end up with something like TUF. TUF doesn't care about low-level details like network requests, so the documentation is tangible. Nobody implements it the same, usually some subset. A mess to discuss.
      • eric: Had concerns that the RFC seems dead. Feel uncomfortable committing to something that doesn't seem like it is moving forward.
      • arlo: Would like to see more details on tap-16. Just rough estimates on the additional http requests for common scenarios.
        • jacob: It has not been used in large-scale production. It is a rough sketch. The good news is that we could influence that design. The bad news is that "just use tap-16" doesn't mean much.
      • ed: Would an eRFC make more sense?
        • arlo: An experiment would be good to see how it works.
        • ed: The important thing is that it is easy to rip out. It shouldn't be invasive. What is the goal of the experiment? How invasive is it to add/remove?
        • arlo: Would like to see tap-16 resolved before even starting that.
      • jacob: Other issues: Companies or CI providers (i.e. GitHub CI) to easily provide mirrors. Currently rely on DNS for root of trust, could help protect if .io goes away (migrating everyone to a "mirror").
      • eric: How does root of trust work for obtaining cargo/rustup in the first place?
        • jacob: You just have to trust your first contact.
        • Could publish SHA signatures that could be verified.
        • arlo: Could do OS signing for more official stuff.
        • ed: Thinks josh was looking into signing, and that morphed into this. Would be good to have input from him.
      • eric: Is there a different ask that we can do in the next 6 months?
        • scott: Would be good to have a discussion with walter/josh to figure that out.
        • jacob: Daily updates, or weekly meetings to have contacts.
          • Don't want to encourage a big RFC drop.
        • arlo: How do we encourage smaller issues, or more incremental work? But not have to answer every question.
        • ed: eRFC with an RFC at the end for the goal of the next six months.
        • arlo: tap-16 could be done outside of cargo.
        • ed: Can this broken down into smaller steps, or things that can have separate conversations?
          • jacob: Index could have a snapshot mechanism independent of TUF.
        • eric: Invite walter to our meeting?
          • Or office hours.

2025-01-14

  • ehuss: Changelog, where to put it?
  • epage: JSON Schema generation
    https://github.com/rust-lang/cargo/issues/12883#issuecomment-2567241649
    • Tracking config source on a per-field basis makes it difficult to pull out the struct definitions for reuse
    • Could switch to per-lookup tracking
    • Would make the code not as clean
    • Config-relative paths, serde structs need to know about the config loader (tightly coupled).
    • Moving config to cargo-util-schema (to generate), the Value wrapper needs to have knowledge of the config back-end.
    • eric: Some config types aren't accessed in aggregate.
      • ed: Could have a cfg for those specific cases.
    • ed: How does merging work, struct or field level?
      • When loading the files, the TOML tables get merged while the files are loaded. Environment overrides are special, and processed when accessed. Environment variables make merging messy.
  • epage: should we deprecate and remove package.authors? See https://github.com/rust-lang/cargo/issues/15027
    • authors is currently soft-deprecated, pretty much unused in Cargo, but no warning.
    • Now default removed from clap.
    • Request to have opt-in to set authors in cargo new.
    • Proposal: Be more aggressive removing/deprecating in docs, once we have lints generate a warning, then possibly remove it later.
    • weihang: Is author the only one?
      • [badges]. Pretty mutch unused.
    • weihang: And the environment variable?
      • No change, deprecating will make people stop using it.
    • No objections. Will also close this issue.
  • epage: Topic

2025-01-07

  • FCP reminders:
  • weihang: turning cargo into a subtree
    • https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Turning.20cargo.20into.20a.20subtree
    • Previous team discussion on this is on 2023-05-09 https://hackmd.io/1mrhxfOsQPWcHwW_5540zA
    • Raise visibility. Give a response whether or not we want to.
    • rustin: Is this bidirectional?
      • scott: It is bidirectional. The intent is to allow modifying cargo in rust-lang/rust, like changing the output of something.
      • weihang: Changes in rust-lang/rust should be approved by the cargo team. However, there were concerns about blocking on that for small changes. I have concerns about outsiders not knowing why tests are structured/written the way they are.
      • ed: Dealing with conflicts doesn't seem ideal. If changes are made in rust-lang/rust, have those upstreamed immediately, not burden on weihang to resolve conflicts.
    • weihang: we don't know until we do it.
    • ed: How hard would it be to go back to a submodule.
      • eric: assume it should be fine.
    • rustin: What does the conflict process look like?
      • weihang: It's just like a normal git merge conflict resolution process.
    • arlo: What other groups have done this?
      • miri, clippy, rustfmt, rust-analyzer, cranelift, rustc-dev-guide
    • scott: How often does it hit the problem that changes are needed in rust-lang/rust? Is it worth the effort?
      • weihang: mostly the test assertions. People feel frustrated because it can take a long while to get their PR unblocked. To us it doesn't seem like a big issue, but to them it feels out of their control.
      • weihang: Could help with nightly things like build-std
        • eric: Doesn't
    • weihang: could pause, let jakob know our thoughts.
    • arlo: No clear indication of who is having specific issues. May not know if it might make it better for people making changes.
    • eric: Has concerns about the closing of issues between repos.
    • weihang can respond just to let jakob know about our thinking.
  • JF: While we are change hash… https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/while.20we're.20breaking.20stable.20hash
    • Is this worth it now that we missed the beta window?
    • ed: Option to revert in beta, and try to do things in nightly.
    • ed: Being explicit has some level of sense.
    • scott: Another option is to scrap derive entirely.
    • jacob: Breaking Ord causes thrashing in the lock file.
    • jacob: Everything is hand implemented right now except for Hash. We could replace the long comment with a short summary.
    • scott: If we do derive, then it would be good to revert on beta and make the changes on nightly. But if we hand-implement, then we can just update the comment.
    • jacob will update the comment and keep the hand-implementations.
    • scott: Had some concerns about Ord and Hash being different, and discussed possibility of changing that in a Cargo.lock version update. However, it was noted that we would have to retain the same code (double as much) to be compatible across versions, which makes the situation worse, not better.
  • [arlosi] Merging lists between configuration files doesn't make sense for some config options
    https://github.com/rust-lang/cargo/issues/14906
    • PathAndArgs such as registry.credential-provider
    • arlo: recommend hard-code keys that are not supposed to be merged. When loading (low-level), just check that list.
    • ed: Would it be possible to delay the merging of lists, and merge at query time.
      • arlo: Haven't prototyped that option, yet. Uncertain how hard that would be to implement.
    • ed: Would like to avoid these hacks, but if there is a reasonable route to do it less-hacky later.
      • arlo: Can add a note about trying to do the less-hacky way.
  • epage: Default values vs missing fields in schemas?
    • People are wanting to infer whether workspace_default_members is supported or not based on its presence in cargo metadata output. Seems like we can't make the field optional if its default as that could be a breaking change. Is this something we should keep in mind for schema design?
    • see https://github.com/crate-ci/clap-cargo/issues/62
    • Can't make the field optional again, since it would be a breaking change.
    • In general, should we include the value of a field if it is set to its default?
      • Example: default-features field for a dependency, a workspace with a 100 members * N dependencies, would be duplicated for each one. Could balloon quickly?
    • scott: Can this policy be changed in the future?
      • ed: Can't change for existing fields, but new ones we could.
    • ed: Could make a note on the plumbing stratetegy to keep the performance in mind.
    • rustin: Can we add an extra flag to control the behavior?
      • ed: Could be messy to make the deserialization conditional. This would probably need to be a new format version.
    • Not including defaults is a two-way door.
    • arlo: For the index, we've had some fields we wish we had left as optional to keep the index smaller.
    • ed: Could put in contributing guide, schema evolution document, guidelines for skipping defaults and such.
Last changed by 
 
rust-cargo-team
Cargo team for the Rust Programming Language
1
1
2888

Read more

Build Times: Cargo Perpsective

Notes to prepare for 2025H1 Project Goal planning

Mar 19, 2025
2025 All Hands Topics

Discuss https://hackmd.io/-jpsOWYoRACRNF3G80Hkuw?edit

Mar 14, 2025
This Development-cycle in Cargo: 1.86

This is a summary of what has been happening around Cargo development for the last 6 weeks which is approximately the merge window for Rust 1.84.

Feb 25, 2025
This Development-cycle in Cargo: 1.88

This is a summary of what has been happening around Cargo development for the last 6 weeks which is approximately the merge window for Rust 1.87.

Feb 18, 2025
Read more from rust-cargo-team
Published on HackMD