Try   HackMD

Cargo team meeting notes 2024 Q4

2024-12-17

  • Cancelling next two meetings?
    • agreed, will cancel until jan 7
  • epage: task bar FCP: https://github.com/rust-lang/cargo/pull/14615#issuecomment-2546346489
    • term.progress.taskbar = true
    • josh: is there a path where we don't need this in the long-term (to avoid maintaining it)? An environment var opt-out. Thinking about long-term where we might not want a config option.
      • ed: Some people like having the option to turn it off it is something they don't want (visual concerns, unusual compatibility, etc.).
  • epage: switch cargo publish to run a check instead of a build?
    • https://github.com/rust-lang/cargo/pull/14930
    • scott: Can you replace the check with clippy?
    • ed: Concern over check not having broad coverage, since assume that people are assuming it is doing that.
    • eric: more than linker errors: https://github.com/rust-lang/rfcs/pull/3477#issuecomment-1689213021
    • rustin: Is this only for publish, or is it also package?
      • ed: This is both.
    • arlo: Important difference, what is the package/publish doing different from build/test? Is there a corner case we would be missing?
      • ed: Won't get leakage of features, won't have feature unification.
      • arlo: May be a scary corner for coverage missing there.
    • weihang: Should cargo check run under release profile?
    • weihang: Want more data about concerns from users having performance conerns.
    • scott: If publish is plumbing, what might be the possibility of supporting the ability to control what runs for the verification step.
      • ed: Question on defaults. If we don't want check as the default, then it would be blocked on any ability to generalize the verification step.
    • weihang: There is a long tail of packages that don't do publish in CI, or aren't running separate tests in the publish process.
    • scott: With release tools, the publish verification is more of a sanity check. Worry changing the default without giving an option to change is odd.
      • josh: publish is both, underlying tool for release tools, and the primary command used.
      • ed: Can't do the same verification step as cargo package because of the registry overlay. There's no way for users to simulate that.
      • josh: This is specifically for workspace?
        • Yes
      • arlo: If we added --check, you could use that?
        • ed: Reluctant to add --check, as opposed to a general purpose verification option, but also don't want to get into the design process for that.
    • josh: Have had situations with sys crates having linking errors.
      • ed: Do those not have CI?
      • josh: Common to have a workflow of updating and publishing locally.
      • ed: If master is already green, why does it matter?
      • josh: There are a number of repositories that don't get a lot of value from CI, and the CI is that they build locally before they push.
      • ed: What is purpose of verify step: Sanity check for packaging, or ecosystem health for people without CI?
    • arlo: Can we post on internals for more feedback from users?
    • josh: Doesn't feel there isn't a backwards-compatibility concern here. This is similar to a lint configuration, which can change.
    • josh: This is a last-ditch verification.
      • josh: Would like a very slow transition to make it possible (default) to run tests on the package.
        • ed: Likely too big of a shift to make the default.
    • josh: Would like to see cargo test && cargo publish (as check). But since we don't do cargo test, the full build is the best thing we can potentially do here.
    • scott: Hung up on plumbing or not, mildly ok with check, but would feel more comfortable with the ability to configure it.
    • rustin: Had a project that didn't have the ability to check in certain hashes, and so had to do certain manual steps when publishing. Building help to ensure that everything was working.
    • weihang: Agree with scott, would like to have a long-term plan to make it configurable.
    • arlo: If there are cases where cargo test && cargo publish fails is very rare, then fine with this. Also agree it is a two-way door we can revert or change. Fine with doing just check, seems it seems rare.
    • eric: Not a strong opinion, but inclined to keep it as-is. Don't have a personal impact on publish performance, since it is very rare or done in CI on small projects. Also uncertain without having any data about how often builds catch other things, so it's hard to make a decision on that.
    • ed: Collecting information from large workspaces about impact of publish performance. Or what workflows are you avoiding? (like avoiding dry-runs).
      • josh: Bevy community is another community that might have good input.
    • ed: Will reach out and collect feedback.
    • jacob: Make it well communicated (to at least power users).
    • scott: Could make the change after beta branch to get full amount of nightly time to get feedback.
    • eric: Just curious on what the configurable route looks like.
      • ed: A variety of different routes it could take (cli, manifest, config), exactly how configurable it is.
    • scott: Would like to continue discussion of verify plumbing support.

2024-12-10

  • FCP reminders:
    • Pass CARGO_CFG_FEATURE
      • CARGO_CFG_FEATURE=a,b,c
      • josh: Can this be CARGO_CFG_FEATURES plural?
        • ed: This is matching the cfg value you see in the code #[cfg(feature="...")], and how all the other cfg values work (like CARGO_CFG_TARGET_FEATURE=mmx,sse).
        • ed: Interested in supporting the ability to pass cfg=value style features.
        • ed: What team would be responsible for having std support ability to get the cfg value (cfg_value!, cfg_values!)?
          • josh: I think adding this would be in the domain of lang and possibly compiler?
      • josh: What about escaping here? If we support strings (key-value), they could have commas.
        • ed: Mutually exclusive features pre-rfc, instead of being in the feature key, the feature name was the key, the value was the value in the config.
        • ed: For key-value things, it could look like cfg(global::foo="10"). This wouldn't be in the features table.
        • ed: These are two separate systems. The environment could look like CARGO_CFG_GLOBAL_PORTS=10.
        • For this proposal, it is just a list of names for CARGO_CFG_FEATURE. The mutually exclusive pre-rfc proposes to have those be new keys.
      • weihang: nit, how does the user detect dep:pkg?
        • ed: If the cfg doesn't exist, then the environment variable wouldn't set it. For example, check-cfg would warn if you tried to use a cfg for that.
        • arlo: Being a little clearer in the docs could help.
    • stable registry hash
      • eric: only concern was creating a new copy after the transition.
      • scott: could there be a transition over time?
      • jacob: Could there be a special case for crates.io.
        • scott: Would prefer to keep the hashes consistent.
      • jacob: Should look for hacks that check for the crates.io hash.
      • arlo: Minor concern over making the paths longer.
        • scott: Could use a shorter blake3?
        • arlo: It would reduce the ability to have hash collision.
      • josh: How long is it?
        • eric: Current hash is 16 characters.
        • 256-bits would be 43 characters with base64
      • josh: Could pick some hash that is shorter?
        • weihang: Could use rustc-stable-hash.
        • arlo: Prefer to not say anything about cryptographically secure.
        • weihang: Only picked that because someone was concerned about it, but I am not a security expert. Uncertain of what kind of threat model there possibly could be.
        • rustc-stable-hash is 64-bits (same what we have today).
        • josh: If you want backup, TC is a cryptograph and can do the analysis of a threat model.
        • jacob: Do we want to switch to base64 anyway?
          • josh: If we aren't changing hash length, then the current is empirically acceptable.
      • weihang: threat model is registry platform can generate same hash as another registry.
      • josh: Can't use base64 since it is case-sensitive and that won't work on (at least) Windows.
        • Could use base36 (~5 bits/char)
      • weihang: Will switch to rustc-stable-hash.
  • cargo package --list shows different whether .git is present or not
    https://github.com/rust-lang/cargo/issues/13691
    • Cargo uses git to derive which files to include in the package. When git isn't there, then it excludes hidden . files (also package include/exclude lists). User was confused by this difference in behavior.
    • ed: For the use case, they can just list the files in the .crate file to determine the list (instead of using cargo package --list).
    • jacob: If we listed the ignores that matched something, it isn't stable.
    • ed: Propose to close, unusual use case. May ask the user why they don't just list the files.
      • josh: Should link to specific section of the documentation that includes this.
    • conclusion: Will close this out.
  • Cargo shouldn't set /WX (-Werror for MSVC linker) outside of CI
    https://github.com/rust-lang/cargo/issues/13620
    • Concern over future versions of MSVC that may issue a warning. ChrisDenton notes that bare warnings are extremely rare. Would prefer that rustc shows warnings instead of hiding them.
    • Proposal at https://github.com/rust-lang/rust/pull/119286 to show linker output even if it succeeds.
    • josh: Support ChrisDenton, very unusual to get an advisory warning. In practice, it ensures that linker warnings get shown.
    • arlo: Would rather we don't suppress it.
    • josh: If there is a practical concern, we could revisit.
    • ed: Author didn't remember why this came up.
    • Conclusion: Will close this out.
  • When crates.io gives 429, cargo should back off and retry later
    https://github.com/rust-lang/cargo/issues/13530
    • epage notes it would be good to check with crates.io team about this.
    • Would crates.io's retry limits be too long? IIRC, new publishes are limited to 10 minutes, new versions 1 minute, but there is also a "bucket refill" logic, don't recall how that works.
    • There is a retry-after header we could use.
    • ed: In cargo-release, my concern was it is worse to ctrl-c, and then the entire release process is interrupted and you have to recover. My recommendation is to talk to crates.io to raise your limit.
    • scott: Can it print a warning, and then wait?
      • ed: My opinion is to error up front if possible. cargo-release pre-emptively guesses the limit, and there is a flag to override it.
    • scott: Can cargo query crates.io for the limit ahead of time?
      • jacob: Doesn't 429 include a header when to try again?
        • Yes, retry-after
      • jacob: Can this be a response to the publish response, what the limits are?
      • cargo publish --workspace would do the first one, and monitor the rate limits, and wait.
      • ed: Similarly concern, the user would interrupt it mid-way.
      • This ties into the issue about supporting a batch publish.
      • josh: cargo publish only can publish one workspace at a time?
      • ed: I've hit the limit of publishing separate workspaces (since it is per-user).
      • josh: Confirm, there is an unstable cargo publish --workspace? Yes.
        • Stopping if you are above the arbitrary limit?
        • Wondering about including the same kind of logic that cargo-release has where it guesses the rate limit, and warns the user, and requires an option to override that.
      • ed: The most ideal solution is for crates.io to tell cargo the available burst.
      • josh: Asking crates.io to give it to us would be reasonable.
      • ed: We could do a lot more work in designing this. But (biased), you could use a tool like cargo-release which does the high-level work here.
      • ed: It either needs to be opt-in or opt-out.
      • arlo: Opt-out of the waiting would be my preference, since otherwise the default is a partial/broken publish.
      • josh: Some 429 waits are not reasonable to wait for since some are 24 hours.
      • scott: Would prefer to discuss this with crates.io team.
      • rustin: What is the main purpose of this limitation? The limit is to avoid automated tools (an anti-spam essentially). The new version limit is separate from the new crate. Should ask them if this is to avoid automatic tools claiming crates, then we could do a retry or backoff.
      • josh: Was the concern about resuming from the middle?
        • ed: Doesn't know how things exactly are for release-plz.

2024-12-03

  • Project goals: deadline yesterday but review is on 11th. The later you are late, the less likely it will be reviewed
  • home directory undeprecation
  • RUSTFLAGS and --remap-path-prefix, https://github.com/rust-lang/cargo/pull/14830#discussion_r1866296742
    • The current issue is that RUSTFLAGS does not affect extra-filename or metadata. Changing RUSTFLAGS thrashes the cache. The intent is to split these two, which allows separate files without affecting symbol names.
    • This is a problem with --remap-path-prefix because it seems to affect reproducability.
    • Can wait for -Ztrim-paths to stabilize.
    • Go back to parsing RUSTFLAGS and stripping out --remap-path-prefix.
      • One idea is to just detect the presence of --remap-path-prefix, and fall back to the old behavior of not affecting extra-filename.
        • arlo: Could be difficult to debug if you didn't know about this?
    • weihang: Could the compiler provide a crate that we could share CLI parsing?
      • epage: The compiler uses getopts.
      • Could make releases more complicated due to the cyclical nature.
    • arlo: Could add a flag for untracked flags.
    • josh: With -Ztrim-paths, will it just work?
      • ed: Yes, essentially it means users don't need to use RUSTFLAGS. However, some users may want to customize the --remap-path-prefix with RUSTFLAGS in ways that -Ztrim-paths doesn't support.
      • ed: One of the problem is split-debug. The per-codegen debug file has the rlib filename inside of it.
    • eric: Can the debug leak be fixed, or is it fundamental to how it works?
      • ed: unsure
      • weihang: The main debug developer has stepped down.
      • ed: Parse the RUSTFLAGS, leave the
      • weihang: With the full trim option, it shouldn't leak into.
    • weihang: Can partially stabilize the full or no-trim, just not the partial trim options.
    • josh: How ridiculous would it be to give flags to rustc, and have it tell cargo the uniqueness hash, and then rustc decides what goes into that.
      • ed: Concern about performance hit calling into rustc.
      • josh: Just need to pass in RUSTFLAGS and cargo config. That would be cached.
      • Or, rustc could just extend the extra filename automatically.
    • arlo: Are there other things besides remapping that are an issue?
    • eric: leans towards the hack of detecting --remap-path-prefix and disabling the change.
    • jacob: Make it clear that the hack can be removed when trim-paths is stabilized?
      • ed: We can reevaluate the hack when it is stabilized.
    • Conclusion: Will move forward with ed's hack, and evaluate as we go along (can always revert).
  • cargo doc –examples … aborts if there are no examples
  • "Cargo install" should provide download binaries only from crate.io if availibale rather than build these binaries every time when calling cargo install
    • https://github.com/rust-lang/cargo/issues/13994
    • Arlo: If crates.io somehow had the infrastructure for this, would make sense to support that, but without first-party support for that, probably wouldn't want that.
    • ed: cargo install is unlocked by default, which would affect this. Is also affected by many other things (flags, env vars, etc.).
    • Would need to finish per-user caching, then network caching, etc…
    • Rustin: Very hard to implement this with other registries. Would have to integrate with some system for building the binaries.
    • ed: Alternate solution is to have a reactive cache, where there is a service with a build queue, and the manifest can tell crates.io what options to use, and then cargo install could install from that cache.
    • eric: uncertain if keeping this open is helpful since it is a years-long project.
    • ed: can be hard on users to close, since they might not feel like being heard.
    • rustin: Could also address why cargo-binstall couldn't be included in cargo by default.
    • Conclusion: S-blocked, will update description to make it a little clearer what this is asking. Also describe why it may not happen anytime soon.
  • cargo publish should refuse an out-of-date lockfile
    • https://github.com/rust-lang/cargo/issues/13986
    • Does --locked work with cargo publish?
      • ehuss: Just tried, it doesn't work (is ignored).
    • Could be a problem if you don't check in Cargo.lock.
    • The rewritten Cargo.lock is not the same as what is checked into git.
    • Conclusion: Should probably make --locked work.
      • eric: That would require special logic for cargo publish.
      • weihang: How do we detect it is a subset?
        • ed: Could force a resolve before doing the trim. Require the entire workspace to be up-to-date.
  • Add --all-features to cargo add
    • https://github.com/rust-lang/cargo/issues/13936
    • ed: Personally against. There are some complexities around which version it picks (oldest, latest). Anti-pattern to be blindly enabling all features. But also open to other opinions.
    • eric: Concern around private features, internal features, mutually exclusive features, etc.
    • josh: If considering this, would make sense to have an "all" feature (similar to "default"), but we shouldn't, and thus should probably reject this.
    • arlo: Would be nice to detect when missing features are being used.
      • ed: rustc has improved this over time, but it has limitations.
    • Conclusion: Close this as we don't want to add this.
  • Cargo updates registry index on every command
    • https://github.com/rust-lang/cargo/issues/13712
    • eric: Could be a good cargo lint, with the ability to suppress it like in a Docker environment or whatever.
      • ed: Would want to have a user/system-level lint, not a project-level lint.
      • josh: Doesn't have to be the lint system. This is just suppressing Cargo messages about user configuration; that could be in .cargo/config.toml without allowing arbitrary lint control there.
      • josh: On the other hand, we don't have to have a way to silence this warning before we add it.
    • eric: Could also be an always-on warning, don't feel strongly. Just uncertain how often that actually happens (legitimately). Being unable to silence is just kinda hard on the user.
    • Conclusion: Add an always-on warning, and if people have issues with that we can consider removing it.

2024-11-26

  • davidtwco: build-std
    • Arm interested in pushing forward. Benefits sharing same flags/options.
    • Adam or Harry Pulls
    • Draft RFC for MVP for build-std. Make sure compiler and libs are happy. Informed decision that this is the right approach to take.
    • Double-check that cargo team is interested in seeing before opening a goal.
    • jacob: Yes interested, lots of details to get into.
    • josh: Historically the problem has been people are excited, and that leads towards scope creep. Driving forward a subset with well-defined boundaries would be good.
    • david: Hope RFC will survey what people what people want to avoid precluding those future use-cases.
    • eric: current bottleneck is review..
      • ed: Had trouble with reviews with whether something makes sense. Getting the full context, large feature, hard to catch up.
      • david: That's our plan for what we plan to provide.
      • ed: May have other projects that are higher priority, so time might be limited.
      • weihang: Don't have knowledge of all the use cases. Inside Amazon, we just use basic build-std (and with whatever features). If we stabilize, how much is explicitly stabilized?
    • ed: Some people want things like optimize for size, but that's going to be another flag for the standard library. Worry about how much libs-api is willing to commit for stabilization.
    • weihang: Another use case is wasm, which has a lot of unstable features. It won't help at $work since those are unstable.
    • josh: Re what libs-api is willing to support. No feature flags are ready for stabilization. Could rename them to mark them as unstable. True with any team, if we can get something that reliably works, just building the standard library, and no additional surface area, that has the most likelihood of success. "No more than one controversial thing at once."
    • david: Sanitizers would help to be built with the same flags.
    • jacob: Some people who walk away from unstable options would be more gravitated towards something like this once it is stable. In particular, minimum support where you can do CPU=native style building.
    • ed: Interesting capability in cargo to be able to build this monolithic thing. Would be nice to generalize that to be useful for other similar problems.
      • ed: Not suggesting this is something that should block it. Just highlighting the depth of the change.
    • david: next steps. There is interest in the cargo team. Work out, summary of the feature, what people want, what we're not going to do, and how we plan to implement that. After discussing with the Cargo team, we help with implementing, and then ask for the cargo team for reviewing that.
    • arlo: Cross team interactions, having you here helps a lot.
      • david: Also talked with Amaneiu and Josh, and compiler, and all interested in well.
      • ed: For unstable features, would the libs want it to be enforced unstable (versus just named "unstable").
        • Josh: Primary goal is to not support those indefinitely. If being able to enforce those more strongly would be great, but doesn't feel it needs to block on that.
        • David: Wesley's idea, supporting .crate files in rustc, and those files indicate limitations or what flags it was compiled with, or what should or shouldn't be used. That simplifies what cargo needs to understand. That file could be produced by bootstrap. That can encapsulate more about how to do the build. (This is one possibility.)
        • ed: Is this a variant of being able to specify the source?
        • david: Not exactly, or at least doesn't need to be exposed that way.
        • josh: Having rustc being able to read into .crate could help blur the line of the integration.
    • Conclusion: Will commit to goal to review/approve strategy.
  • FCP Proposal reminder: Cross-platform stable source hash: https://github.com/rust-lang/cargo/issues/14795#issuecomment-2498445073
  • epage: project goal ideas https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Project.20goals.20for.202025h1/near/483579936
    • particlar fine grained target locking
    • orphaned goals. important areas that we would like to see move forward.
    • Would like to break goals down smaller. User caching could be broken down. target directory reorganization could be a sub-task to help with that. Locking individual artifacts. There wouldn't be fine-grained locking for final artifacts. Or things that don't set extra-filename. Not completely fine grained. But might at least prevent rust-analyzer and cargo command-line blocking one another.
    • Arlo: Like the idea. Uncertain about how this is needed for per-user caching.
      • ed: Eventually have racing over who moves into the shared cache first. Also want to avoid garbage collecting something in -use. Assume wanted to lock individual artifacts in the shared cache.
    • eric: cargo used to have fine-grained locking, but it was removed, but don't remember why it was removed. (Or maybe that is the index cache?)
    • ed: shared cache location would have each package in its own directory. The idea is to move the target directory to have the same organization.
    • arlo: How does that work with the compiler expecting everything in the same directory?
      • ed: Would need to pass a flag for each directory. This would be needed for per-use cache as well.
      • ed: One of the problems with the prototype was copying files in/out.
    • ed: Goal is unstable support. Would need a transition plan for tools that access the target directory directly. See if we can get it working, and evaluate from there.
    • weihang: Crazy idea. If cargo was a daemon, would it still need a lock?
    • conclusion: OK if this is something ed wants to pursue.
  • cargo metadata: provide an option not to collect data about dev-dependencies
    • https://github.com/rust-lang/cargo/issues/14794
    • They vendor. They have a local index so they can do a local resolve. But when cargo tries to do anything else with those dependencies, it has to parse the manifests, but the dev-dependencies are not vendored, and thus it fails. They can get away with dev-deps in the index, but they want it to avoid touching the manifests, not failing when they are not present in the vendor directory.
    • -Zavoid-dev-deps doesn't quite do what they want for cargo metadata. It's in the name, "avoid" doesn't mean "never use". They want -Zavoid-dev-deps to work with cargo metadata to really avoid dev deps.
    • SBOM would be a complete solution. Their use case is cargo auditable.
    • jacob: Why is SBOM stuck?
      • arlo: Just need to push PR. (and update RFC)
      • ed: Can review if you push.
      • jacob: Resolution could be "let's get SBOM unstuck"?
    • ed: Also don't know how avoid-dev-deps will ever be stabilized. Could just change it for cargo metadata, and if someone wants to get it stabilized, it would be on them to figure out what cargo metadata should do.
    • conclusion: Can change cargo metadata behavior (since this is somewhat experimental), and note on the tracking issue this is something to figure out. Also, the real solution is SBOM support which hopefully Arlo will be able to move forward.

2024-11-19

  • Pull out the HTTP mock server as cargo-dev-registry
    • https://github.com/rust-lang/cargo/issues/14834
    • make this a reference implementation, could also be used for unit tests
    • kellnr does exist
    • cargo-test-support has part of one
    • pull out common code into cargo-util-schemas, cargo-util-registry, cargo-dev-registry
    • Will move towards improving quality of our test registry, making it easier to do testing (proactively develop it)
    • Pinged Arlo, want thoughts there
    • epage: artifact status?
    • ehuss: failure injection points
    • epage: we'll see
    • ehuss and scott: start with experimental
    • arlo: start with focus on testing, explore it as reference later
    • epage: maybe cargo-util-registry could be intentional
    • epage: experiment is really about
    • arlo: crates-io is already a home for this
    • arlo: name is weird
    • ehuss: keep separate as the client side has heavy dependencies
    • epage: put those in a feature
    • arlo: start new, move things over
    • weihang: what about T-crates-io
    • epage: this is all test stuff and general code, don't need permission
    • epage: keep them informed and discuss
    • epage: they are pinged
    • ehuss: not all registries can share things
    • epage: yes, crates-io goes manifest -> db -> index
    • epage: but still helpful for smaller ones and having types available
    • weihang: maybe conformance tests / test double?
    • weihang: openapi?
    • conclusion: accepted
  • Can't cargo publish --workspace --dry-run if the versions already exist
    • https://github.com/rust-lang/cargo/issues/14789
    • Dry-run doesn't bump version
    • Causes local version and registry version to exist, error with merged source
    • jacob: allow overriding version on publish?
    • ehuss: Wondering about the relationship with --idempotent: https://github.com/rust-lang/cargo/issues/13397
      • epage: if you need it, you are likely big enough to need more
      • ehuss: cargo itself could use it
    • epage: don't conflict, if idempotent the package won't be put in the local registry
    • jacob: make it a lint and make it configurable
    • epage: either one off wart or full lint control
    • epage: maybe framed differently, this oculd be like --ignore-rust-version
    • arlo: but we have lint control?
    • epage: thats static, cargo-release should do it dynamically
    • epage: came to team because we were concerned about this and didn't want to weaken this without input
    • jacob: slipper slope for people staging and then publishing
    • epage: Microsoft asked for something like this
    • jacob: Maybe when we have cargo-dev-registry, maybe there will be better opportunities for this
    • epage: to verify, we're good weakening
    • arlo: make warning rather than error
    • arlo: will this affect people to not error
    • epage: not erroring is what individual packages did say back in 1.70, this will make it consistent
    • arlo: does it warn?
    • epage: yes, as of a couple weeks ago
  • Project Goals
    • https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Project.20goals.20for.202025h1
    • josh: deadline is Dec 2nd
    • scott: roll over?
    • josh: go for it
    • jacob: pubgrub will roll over, trying to figure out how
    • epage: whats holding it back
    • jacob: patches/replacements. not good test cases
    • weihang: sandbox, giving multiple directions, won't roll over
    • weihang: explore another idea
    • jacob: nerdsnipe alex
    • epage: dropping performance
    • epage: talk at all hands, write goals for h2
    • arlo: goal for index mirroring and signing?
    • josh: makes sense
    • josh: Would make sense to have Walter Pearce own this. I plan to work on it.
    • arlo: good for Walter to own this
    • josh: will ping them
    • arlo: offering to help with effort, just not drive it
    • josh: aim for only one goal per owner
    • josh: name "owner" gives bad impression
    • josh: they are "responsible reporting party"
    • epage: a liaison
    • jacob: secretary is a good name
  • Make CARGO_BUILD_TARGET accept multiple target triples
    • https://github.com/rust-lang/cargo/issues/14820
    • josh: shouldn't need special casing like rustflags encoding
    • epage: how does this interact with unstable target paths?
    • josh: do we support it there?
    • epage: don't know
    • ehuss: might just need a tweak for our string-or-array code, may affect other env variables
    • weihang: stabilize advanced-env?
    • arlo: whats the context?
    • ehuss: so experimental, we didn't document it
    • ehuss: question with special magic of open brackets
    • ehuss: no conclusion

2024-11-12

  • FCP proposal: Add future-incompat warning against keywords in cfgs and add raw-idents
  • OK with clippy::correctness?
  • epage: For artifact deps, should we split target support out?
  • epage: Always include Cargo.lock, see https://github.com/rust-lang/cargo/issues/13447
  • 2025H1 Project Goals
    • Moving forward with https://hackmd.io/@rust-cargo-team/H1R-K6Gk1l
      • Josh is working on a project goal for macros
    • epage: Making project goals for "team wants help with X"
      • josh: sounds like a good idea.
      • josh: process not really there for orphaned goals last time
      • josh: even if team was on board, perception was other teams weren't looking at them
    • epage: testing-devex
    • ehuss: how was pubgrub goal?
      • jacob: did well on scope and things went smoothly
      • jacob: accountability from daily updates was useful
      • jacob: question for next goal: what is next measurable item for 6 months?
    • ehuss: semver checks. last blog didn't have updates
    • ehuss: retro?
      • epage: the zulip thread?
      • jacob: he's been asked
    • epage: json after cargo script
    • weihang: sandboxing, going to fail
      • sandbox everything?
      • there are other alternatives?
      • ehuss: haskell has a way to delegate, can run full build in docker. Haven't used, unsure how it'd work
      • josh: would help with his distributed build tool
      • epage: two prong alt: reduce reliance on build stuff and make it easy to audit
    • scott: annotate-snippets rolls over
    • epage: target dir?
      • rustflagd?
      • ehuss: not needing
      • helps in future with gc, caching, etc but no general benefit
  • Style guide for Cargo: https://github.com/rust-lang/cargo/pull/14439
    • What to recommend?
    • Packages are contentious
    • Bins are pretty standardized
    • Framed as recommendation, not prescriptive
      • There are times to do otherwise
      • Disabling a lint is ok
      • Just not emphatic
    • Package layout is odd place
    • Maybe Recommendation in cargo-targets.md

2024-11-05

  • Please look at FCP proposal for resolver v3: https://github.com/rust-lang/cargo/pull/14754#issuecomment-2448872335
  • Discussion at GOSIM resurfaced some ideas about build performance:
    • What debug levels should be enabled by default (e.g. full debug vs file/line info)?
    • What optimization level should the dev profile use? Should it be for debugging or fast building? Because some optimization can speed up building
    • Is debug for fast-build or debugger?
    • Some optimizations make building faster
    • -Ofast
    • Debug profile separate from dev?
    • Related: discussion around changing default optimization levels for --release https://github.com/rust-lang/cargo/issues/11298
    • debugger-debugging (gdb/lldb) versus print debugging (or other debugging techniques)
    • eric: any data on what improvements could be made?
      • recall adjusting opt-level to 1 didn't have significant improvements in the past.
    • scott: can be project-specific (or dependency specific)
    • ed: distinct camps things center around. What is the best/most common out-of-the-box experience?
    • jacob: Reserve a profile name for actual debugging?
    • Would it be a breaking change to add a profile name?
    • ed: Namespaced profile names that are immutable, and then release inherits from one of the immutable ones. Then have more flexibility to change profiles.
    • josh: seems like a breaking change regardless. Any unset property comes from whatever is inherited.
    • jacob: how hard is it to set an arbitrary profile?
      • --profile=foobar
      • If we create a default "debug" profile what we think is best for debugging.
    • ed: profiles already have a discoverability issue, so if there isn't a flag specifically for it, might be hard to find.
    • josh: built-in vs DIY, concerns about dev profile that could be improved has a natural successor. Updating the defaults would not be a big deal.
    • jacob: How many people using debuggers via the command-line, versus an IDE.
      • ed: Would need to reach out to them to see how they could transition.
    • arlo: Adds some more friction, since it triggers a complete rebuild.
    • ed: Would changing target/debug to target/dev be a problem?
      • josh: Would probably cause lots of breakage.
      • josh: A special case in the code to decide, if in default, put into target/dev, and symlink target/debug. If in debug, and target/debug is an symlink, remove symlink and make a directory.
      • arlo: symlinks are still unfortunately trash on windows, difficult to overly rely on them.
    • eric: this is a high cost change, want to see data
      • josh: seen data in past
      • josh: linking is a big issue
      • eric: what about just split debug info
      • josh: small but not complete
    • ed: Collect data on improvements? Ask people to get information e.g. build comparisons with debug information reduced? Look at getting -Ofast added.
      • Get full build, touch lib.rs/main.rs and build, build and test. Multiple stories we could talk about performance.
    • arlo: -Ofast can be a confusing name.
      • josh: That's what gcc and other call it, but agree we should pick something less ambiguous.
    • eric: Sounds good to me to have two separate profiles, one for actual debugging (with debuggers, which few people use), and a default for "normal" development that wouldn't have as much debug information. Would be nice to know exactly which settings would be different and why.
      • eric: And would be good to have a story on how we transition to this new profile (does it need an edition? what is it named? etc.).
  • Can dependencies set default profile settings?
    • sqlx and opt-level 3
    • When we get mir-only rlibs, windows-sys and aws setting it
  • Scott: Switch from bors to merge queue
    • ed: Would like to have self-merge, and require conversations to be resolved.
    • eric: Have concerns about require conversations, since there are some conversations are not actually resolved, but you want to merge anyway, and it also makes it difficult to find conversations. If you search in GitHub, it opens the PR, but then you have to expand all conversations to find the thing you are searching for.
    • conclusion: will try for now, and will switch back if we have too many problems.

2024-10-29

  • heads up: meeting timezone change next week
  • https://github.com/rust-lang/cargo/pull/14435 – cargo::error
    • Eric will rebase/fix PR
    • josh: how to monitor behavior with libraries doing this
      • eric: can add a small note to the docs to let library authors know to consider it.
  • https://github.com/rust-lang/cargo/issues/14685 – cargo package could run tests in the packaged tree
    • Add --test option to cargo package, cargo publish
    • jacob: There are many things people could want, and concerned about using the flag namespace for all those options
    • josh: Two orthogonal things: should there be a way to run tests from a package. The other is how to do that. Shouldn't have cargo package --test when we already have cargo publish --dry-run. Would be nice to have an opt-in way for a package to say it can run tests. Do we want an opt-in for that.
    • jacob: not a boolean opt-in flag for the command line. Running "tests" could be complicated (things like miri, etc.).
    • josh: There be some config option for tests to run on a .crate after building it.
    • arlo: related request that came up at $work is for cargo publish to use a .crate file.
      • https://github.com/rust-lang/cargo/issues/12747
      • josh: also wants that, not high priority. Means you can do 99% of work on a fast build system, but not have publish credentials on that system, and instead download the .crate file and publish it.
      • ed: One of the issues is needing a whole bundle of .crate files. Do you want to be able to verify?
        • arlo: Would assume it is your responsibility for testing.
    • weihang: Can this be done as a plugin?
  • https://github.com/rust-lang/cargo/issues/14721 – checking for published version early breaks cargo release dry run mode (since it can't bump version numbers)
    • New error message that reports if a version already exists. Nice usability, but in cargo release dry run doesn't bump versions, and hits the error. How much do we want dry-run to differ?
    • jacob: awful hack: early error if publishing one package, and a late error if multiple?
      • ed: probably wouldn't help here. Multiple or single doesn't matter.
    • arlo: Why doesn't cargo release bump them in dry run (and then un-bump).
      • ed: Trying to revert edits is messy. Better to not touch filesystem.
      • arlo: How much of dry-run has fidelity with the actual release?
    • josh: Make it an unconditional warning.
      • ed: For the users this was meant to help with, it probably wouldn't help. The intent was to stop the publish early instead of late.
    • arlo: Can it be a lint that cargo release overrides?
      • ed: Lint system isn't designed to be overridden.
    • conclusion: Switch cargo publish --dry-run to be a warning.
  • https://github.com/rust-lang/cargo/issues/14390 – include patterns should report invalid paths
    • Glob crate doesn't exactly tell us which patterns do or don't match.
    • Could be a warning if we could detect it. Would likely want that part of the lint system.
    • This particular scenario was a problem with missing files for a particular platform.
    • arlo: How could they verify all of the platforms?
      • ed: It could be a very slow process of cross-compiling for all platforms on publish.
    • weihang: Could have options for required vs optional to handle the situation where some people intentionally have missing files.
    • conclusion: Would like a warning/lint if it was possible to support, but the ignore library doesn't support the ability, so would have to wait for a solution to that.
  • https://github.com/rust-lang/cargo/issues/14372 – When generating version requirements, use the oldest "good" version within a major version
    • cargo add
    • Don't be aggressive on newer version requirements.
    • ed: Supporting this is difficult because serde doesn't use patch version. It would pick 1.0.0 which would be an invalid requirement for most users.
    • josh: ecosystem does not consistenly use the recommendations of semver. Don't know which minor version you need. Bug fixes or features you are depending on. If cargo is second-guessing… Shouldn't even try. If you want this, make a tool that tries building successive versions for the lowest version that works.
    • conclusion: Ed will close out.
  • https://github.com/rust-lang/cargo/issues/14236 – centralize lint configuration
    • Pulling lint configurations from a remote source.
    • Similar issue in ed's other tool: https://github.com/crate-ci/typos/issues/1129. This is whack-a-mole.
    • scott: "no"
    • josh: Would complicate things like publishing. Sympathetic, would have a general-purpose include mechanism.
      • arlo: That's the only thing I would remotely be before.
      • josh: Not a remote git repo. Run into versioning problems, etc. Include from a path in the repository. If they want to inflict submodules on themselves, that's their option.
    • How ruff does this with an extend option: https://docs.astral.sh/ruff/settings/#extend
    • Cargo's config include is a similar option.
    • ed: Another file format. Would there be different file formats for every extension point.
    • scott: Already have nested workspaces which could be used as a solution. But merging is awful.
    • scott: Concern about the complexity of includes and all the complexities of manifest parsing and workspace inheritence and such.
    • conclusion: Will close. Would prefer general include mechnaism, but not prepared for the complexity particularly in relation to workspace inheritance.
  • https://github.com/rust-lang/cargo/issues/14033 – debug-assertions are implicitly disabled when running cargo test with opt-level=3 set from rustflags
    • conclusion: eric will close, as should be using opt-level, not rustflags. Cargo doesn't know what rustflags are being set.
  • https://github.com/rust-lang/cargo/issues/14032 – Make bench profile set debug = true by default
    • eric: Had concerns in the past that when benchmarking, you want to be as close to release as possible. Debug might have some impact on it.
    • eric: An alternative is to have profiling be a first-class feature in Rust/Cargo.
    • conclusion: Will close.
  • https://github.com/rust-lang/cargo/issues/14017 – Suggested adding dep:foo to the foo feature if it exists for unused optional dependencies

2024-10-22

  • checksum stablization plans: https://github.com/rust-lang/cargo/issues/14136
    • What is UI? switch wholesale, or temp with env var, config thing?
    • weihang: less useful if the build script issue isn't fixed.
      • ed: Is the concern that it builds too often or not often enough?
      • weihang: yes, too often
      • epage: More concerned about it skipping building when it shouldn't.
      • eric: Is there a proposal to fix it?
        • No way for a build script to know which version of a file it saw.
        • Build scripts may also need to provide the checksums.
      • epage: reduce the role of build scripts?
      • jacob: what would we be stabilizing and how do we communicate it?
        • jacob: Would there need to be workflows for different options?
        • epage: documentation for different workflows?
        • jacob: 4 possibilities, neither changed, one or the other changed, both changed.
          • mtime doesn't change, hash does. What should happen?
          • ed: Only reason to check mtime is to elide mtime checks?
          • eric: do we ever want mtime? get rid of it altogether
          • arlo: if we only checksum on no mtime change, then that isn't much of an optimization since the common case is no mtime change
          • weihang: benchmarking?
          • jacob: need to be ready to be able to disable it (env var?) as an escape hatch
      • ed: build-integration Zulip channel, call for testing.
        • weihang: be clear that it may not fix the extra rebuilds (due to build scripts), that it is more intended for imprecise-mtime. More for correctness.
    • ed: path to stabilization, hack this on and fix all test failures, and try to fix all those tests.
    • ed will take care of asking for people to start testing and getting some timing/benchmark data.
    • jacob: Is this helpful/related to the previous
      • weihang: not really
  • https://github.com/rust-lang/cargo/issues/14708 – Add cargo new flag for inserting proc-macro = true into Cargo.toml
    • scott: what about first party templating?
    • Conclusion: will close for templates
    • weihang: is that a general policy for additions to cargo new?
      • ed: how universal is a feature? Consider if the payoff is worth it.
  • https://github.com/rust-lang/cargo/issues/14679 – Where should cargo verify-project go?
    • Almost no verify-project users.
    • ed: Alex was surprised it was stabilized. One of the first commands in cargo, and forgot about it.
    • Can't get rid of it, but can deprecate and hide it.
    • weihang: Expand it?
      • arlo: Prefer to only do that if there is a use case, people wanting to use it.
    • ed: also uses old "project" terminology.
    • ed: interested in putting plubming commands under a single top-level command.
      • uv got good mileage out that
    • conclusion: Will deprecate.
  • https://github.com/rust-lang/cargo/issues/14444 – Tell rustc wrappers which envs to pass through to allow env sandboxing
    • Unstable --env-set in rustc. Breaking change if cargo starts using it.
    • eric: Why wouldn't you just launch cargo with an empty environment if you want a clean environment?
    • eric: Confused, how would it know ahead of time what environment variables it needs?
      • env! would be an error if you don't set it in the build script.
    • jacob: What is the threat model?
    • eric: will ask for more details about the use case.
  • https://github.com/rust-lang/cargo/issues/14442 – CI requires formatting, but the project doesn't specify which one
    • eric: inclined to close, doesn't feel like a global rustfmt is a use case that is a good idea when working on other projects.
    • ed: also inclined to close
    • scott: seems like an anti-pattern
    • arlo: if we recommend it, it could be part of cargo new which I don't think we should do
    • ed: rustfmt recommends everyone has a rustfmt.toml file
      • trying to work out with Caleb, IDEs call rustfmt directly, and don't get the edition for the package. They do that to format a specific file. It gets complicated with per-cargo-target edition. Trying to get it changed so they can call cargo fmt instead. source file to manifest is hard to map.
    • weihang: benefit is for a contributor with a global rustfmt.toml, doesn't seem uncommon. Doesn't feel it justifies to merge this.
    • arlo: cargo fmt when it was a submodule causing it to reformat everything.
      • jacob: That seems like a reasonable reason to do it.
    • jacob: would like to know more about the concerns about rustfmt that motivate changing the defaults.
    • conclusion: Will close as something we don't want to do.
      • scott: long-run, there could be a different approach.
  • https://github.com/rust-lang/cargo/issues/14420 – Option for cargo tree to filter out (non-)workspace members
    • eric: --depth workspace?
    • eric: +0 on the idea
    • ed: Idea makes sense, could be worthwhile to support. Would help seeing a large project. +1
    • conclusion: Will mark as accepted.
  • https://github.com/rust-lang/cargo/issues/14398 – Encoded CARGO_TARGET_<triple>_RUSTFLAGS just like CARGO_ENCODED_RUSTFLAGS?
    • eric: why did we not do this earlier?
      • Probably nobody asked for it.

2024-10-15

Out: Josh, Ed, Eric, Rustin

Cancelled, feel free to use time for office-hour style discussion if desired.

2024-10-08

Out: Josh, Rustin

  • eric: next meeting
    • Since several people are out, officially cancelled, but people are welcome to meet office-hour style and hang.
  • https://github.com/rust-lang/cargo/issues/14606 – With CARGO_COMPLETE, –target, –bin, etc show both values and flags
    • On balance, which is the worse situation:
      • less-good completions
      • remove the "missing" error message
        • cargo -p ? as an alternative to show the list
          • weihang: +1 for this. Maybe something like ipython does that?
      • a deferral system for telling clap what the possible values are, which would be called when there is an error.
        • arlo: fixing on Clap side would be nice. num_args(0..=1) is kind of a lie, since it isn't declaring what we actually want.
        • ed: also, something like cargo build -F serde -F doesn't work, since there is already 1 argument.
        • ed: also thinking about a validation plugin system for clap, with a clap trait. The problem is the order of validation (built-in validators like num-args would need to go after).
    • scott: any way we can have clap_complete work correctly, and have error handling work (in any way).
      • jacob: and the error handler could say "and here are the possible options to fill in here" using the same facility that the completion uses.
    • eric: personally haven't made use of the error case, uncertain how common it is, hard to get data on that.
      • jacob: completions are not widely available today
      • ed: Could possibly support other shells like powershell in the future.
    • ed: Could be quite difficult since the parser doesn't really have the context. Currently the statically-known ones work.
    • More investigation to see what's possible here.
  • https://github.com/rust-lang/cargo/issues/14555 – Saving a specific message-format to a file, while also producing "normal" output
    • Cargo mixes stdout/stderr for different cases.
    • eric: In this case, wondering why the tool doesn't just print the rendered output?
    • arlo: are there cases not included in the json?
      • eric: Some cases for cargo-specific output, like downloading git dependencies.
    • conclusion: recommend using the JSON, and json message if anything is missing.
  • https://github.com/rust-lang/cargo/issues/14506 – Make empty/default fields in the index metadata optional
    • ed: Wouldn't really work for crates.io for old cargos, but could work for other registries. But this issue might be focused on edition or msrv.
    • jacob: Probably never going to be able to take advantage of these defaults. Old cargos will always fall over. It would be nice for other registries and test files. Would need to be carefully documented. Let's do it, but never take advantage of it for crates.io.
    • arlo: Could high msrv support it?
    • ed: older cargos will ignore things it can't parse.
      • Similar to the problem before where new syntax causes bad error messages for older versions.
    • Serialization is on the crates.io side.
    • weihang: Would it be possible for some fields to have a different default value?
      • arlo: Shouldn't be an issue since we regenerated the index.
      • jacob: These fields have always been required.
    • conclusion: move forward, but not for crates.io in the indefinite future, clearly document. In the far future we can possibly consider edition or msrv-specific behavior on crates.io (just be aware of the bad error message pain).
  • https://github.com/rust-lang/cargo/issues/14460 – Seamless upgrade from 0.x to 1.0
    • Uncertain how often this actually happens.
    • Jacob: Where would this metadata live?
      • In the index. Per-version, or crate-level. If crate-level, we don't have space for that.
    • arlo: initial response is to say no
    • ed: libc is a major example. Popular vocabulary crates.
    • arlo: Would like to know why more crates haven't moved to 1.0. Feel like it is likely more than this.
      • ed: over-cautious about what 1.0 means.
        • two-factors:
          • Making breaking changes after 1.0 feels not as great
          • Matured enough, but enough stigma against 1.0, and take minor version and make that my major version (cargo-release 22.0.0).
    • eric: feel like more of a postpone. More information is needed at this point.
      • and a detailed discussion of where the information lives and how the resolver deals with it.
      • violation of semver, feels bad.
    • Might be good to move mention of semver-trick to the semver-compatibility section.
      • Ed will look into this.
    • conclusion: close/postpone for now.
  • https://github.com/rust-lang/cargo/issues/14455 – cargo rustdoc does not document lib tests
    • eric: Personally don't use this workflow of documenting private items, so uncertain about how people use this or how common it is. I see a few people use cargo doc for private items.
    • Significant implementation problem due to collisions. Would need to just do the library once as a test.
    • eric: Fine with the general idea, but uncertain how difficult it is.
    • eric: I'll take it on to spend 10-15 minutes to determine how difficult this might be, and leave a comment with the conclusion.
  • arlo: Would like to go faster to be more effective, more of a vibe check than figuring out the technical solutions.
    • Would be nice to have a lighter solution, like a +1 to close or accept, so that we don't need everyone's input on everything.

2024-10-01

  • eric: removing implicit features
    • wondering if better error message for a/b would work?
    • ed: volunteering to remove the implementation, too much risk since next week is go-no-go
  • eric: FYI for visibility: --print=std-support https://github.com/rust-lang/rfcs/pull/3693
    • josh: can rustc expose this information in one command with other things, so we don't need to run rustc --print multiple times?
      • yes, cargo does multiple --print options in one invocation, and assumes they are printed in order.
  • eric: FCP to postpone seems stuck
  • eric: stuck FCP Review
    • "Give users control over feature unification" https://github.com/rust-lang/rfcs/pull/3692
      • jacob: How much needs to be decided now, and how much can be deferred
      • ed: mostly concerned around the name to not block future possibilities
      • eric: wondering about the use cases for package, since it seems like it would be a compile-time hit for packages that are both top-level and dependencies.
        • ed: Mostly intended for CI workflows to ensure individual packages work on their own. May not really be used outside of CI.
      • eric: Wondering about also setting in the manifest (mentioned in future possibilities).
        • ed: Didn't want to block on figuring out the exact schema (changing resolver-version to a table, etc.). Intended use-cases is for something that changes.
        • eric: Thinking of a project that wants a permanent setting for a workspace, and doesn't want to have two files (Cargo.toml and .cargo/config.toml).
          • But we can figure that out when we find there are users actually doing that and asking for it.
      • arlo: no-std and std in the same workspace, package style unification.
      • weihang: How would this work if there doc-dependency or other target-specific dependencies.
        • ed: Build-target unification is outside of the scope here. This is mainly for packages specified in the command-line.
    • config-include https://github.com/rust-lang/cargo/issues/7723
      • https://doc.rust-lang.org/cargo/reference/unstable.html#config-include
      • FCP: https://github.com/rust-lang/cargo/issues/7723#issuecomment-1602641051
      • last concerns were about use cases, some users since
      • weihang: Some people would prefer it to not be an error if the config is missing.
        • arlo: Could be confusing for people who don't want it to be optional. Would be nice to have some middle-ground.
      • Arlo: Would be good to stabilize cargo config get so that you can actually see where config options are coming from.
      • josh: Would like to stabilize and extend it later as needed.
      • jacob: Multiple config files with different ownership within an organization. Socially reasonable to say different teams have ownership over them (not a technical reason to have them separate).
        • weihang: Also brings back that some options should be in manifest if they are not optional.
      • weihang: No longer needed at $work, but can still drive it.
      • eric: Wondering if we should make it a table now to make it easier to extend in the future. Ala Josh's proposal to have include = { path = "some.toml", optional = true }.
        • arlo: It sounds good if we intend to extend it in the future.
        • arlo: Could also be array of table syntax.
      • arlo: How does this work with environment variable or CLI?
        • eric: --config <path> is already stable.
          • eric: Not documented terribly well, we should at least include in -h and https://doc.rust-lang.org/cargo/reference/config.html.
          • eric: The whole reason this exists was to support --config. The only reason it is also supported in config is that was how it was implemented, and I had a vague idea it would be clever, and similar to how .gitconfig works.
        • Does --config include=... work?
          • weihang: Yes
          • arlo: For consistency, that's good that it doesn't work. Just that it doesn't work with environment variables is an inconsistency. Might be nice.
Last changed by 
 
rust-cargo-team
Cargo team for the Rust Programming Language
0
31

Read more

Cargo team meeting notes

https://meet.jit.si/CargoTeamMeeting

Mar 25, 2025
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
Read more from rust-cargo-team
Published on HackMD