Try   HackMD

Cargo team meeting notes 2024 Q1

2024-03-26

  • eric: Stable release for Windows MSVC backtrace issue?
    • Not beta-backported yet
    • Is a tier 1 target
    • Release team was ok with it but didn't push it
    • Can workaround by manually setting strip option
    • Why?
      • There isn't separate debug vs symbol stripping
      • So they default debug stripping to include symbol stripping
      • They are likely to change this but wanted the change in cargo first
  • arlo: gitoxide stabilization for list_files_git
    • Also discussed at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60gitoxide.60.20integration.20updates/near/428383923
    • arlo: Doesn't feel we should go in the git cli route, that gitoxide should be enough.
      • Environment variable escape hatch just in case to go back to libgit2
    • There was discussion of running both side-by-side to catch when they diverge to detect if it is the same.
      • Or in addition to the env var.
      • Arlo has done some testing to verify they are equal on some complex projects.
    • How do we handle this?
      • Running in parallel could have some performance issues.
      • Likely would run them serially.
      • ed: not concerned about performance, especially if it is temporary.
        • Could run it nightly only, and then when hitting beta remove the parallel runs.
          • (If we are concerned about performance.)
    • eric: do we have performance numbers
      • no
    • weihang: Boundary for new git config?
      • Is it a breaking change to switch the backend when different backends have different git support?
      • ed: The git cli could be a good fallback.
        • arlo: agrees, if we do have to revert gitoxide, then would probably want the git cli option.
    • To clarify: "in parallel" means running git2, and then gitoxide. Ask the user to report if there is a divergence it (except when git2 fails and gitoxide succeeds).
    • There are concerns over the paths being not normalized, so it needs some subtle comparison work (try to avoid canonicalize).
      • ed: Wonders what normalization we want.
    • eric: beware of dos naming, particularly in new libgit2 1.8 update coming soon.
  • epage: dependency inheritance
    • https://www.reddit.com/r/rust/comments/1bjdnne/cargoautoinherit_dry_up_your_workspace/
    • Over time, been leaning towards workspace.dependencies should only contain source
    • Problem is the default for default-features can sometimes require putting default-features = false in workspace.dependencies which requires some packages to do default-features = true (https://github.com/rust-lang/cargo/issues/12162)
    • cargo add is likely broken wrt when adding an inherited dependency and adding to workspace.dependencies (https://github.com/rust-lang/cargo/issues/10608) will make this problem more visible
    • three directions
        1. Like how it is, keep it.
        1. Deprecate everything except source.
        1. Focus on the one case of default-features
        • In edition, change workspace dependencies of default-features not specified to be "unset", and then allow dependencies to set it.
    • jacob: for edition, wouldn't that be an issue since workspaces don't have editions?
      • ed: The behavior would affect how the package inherits the workspace. It doesn't change the workspace itself.
    • scott: In the future we could have a warning if the editions are different. That could maybe help with treating the entire workspace as a single edition.
      • ed: Considered that future probably a clippy-style lint of being pedantic.
    • scott: Biggest issue is keeping features at the workspace level. But you would need to explicitly say "default" in the features list.
      • ed: not necessarily. in the transitional case of just restricting default-features, when not specified as "unset" defers the decision to the package. Can set default-features=true to force the current behavior.
        • Today: you get a warning when you set default-features=false in the package.
        • The proposal is that default-features in a workspace is Option<bool>. In the None, state, the package gets to decide the default-features setting.
        • What happens when packages conflict?
          • It unifies to be default-features=true if they are both built at the same time. If built separately, then they get whatever they specify. (The same as normal feature unification.)
    • ed: It does seem there are some use cases for features like serde's "derive".
      • How much are features implementation detail or shared requirements.
      • Feels consolidating the source is the most important aspect of inheritance.
      • scott: concerned about taking away functionality.
    • scott: May want to consider banning new fields inherited in the future.
    • ed: What do people think of changing default-features in a future edition?
    • rustin: what about the "deprecate everything" option?
      • ed: There were some concerns raised about the fact that some things like features are being used (possibly particularly in closed source/larger projects).
    • There are some complications with workspaces not having an "edition", how members would interact if they have different editions.
    • jacob: For the "unset" behavior, that setting the default value changes the behavior.
      • First principles solution may not be what the user is expecting.
    • arlo: documentation concern to communicate this clearly since workspace.dependencies deviates from dependencies
      • epage: we do define the tables separately, making this easier
      • jacob: the term "default" shows up a lot, making it harder
    • hi-rustin: user transition cost / ecosystem churn (user education, etc)
      • Affects docs in terms of documenting behavior per rust version to help people on older versions or support older versions (MSRV)
    • using workspace.dependencies as workspace-hack
      • This is more if we deprecate features
      • Still incomplete unless every package shares the same dependencies
    • How do we help people find why a feature is enabled

2024-03-19

  • epage:
    • Status:
      • project vs package
        • warn if both are present, saying which will be used
        • if project is used, warns this may become an error in the future
      • build_dependencies vs build-dependencies
      • dev_dependencies vs dev-dependencies
      • default_features vs default-features
      • proc_macro vs proc-macro
      • crate_type vs crate-type
        • warn if both are present, saying which will be used and saying it is deprecated
        • no warning just on _ use
    • Questions
      • Should we deprecate _ variants?
      • Is it time to address our "error in the future" cases?
        • Always error or tie to an edition?
    • Weihang: Believes this dates back to using RustcSerialize
    • Weihang: Do we even need to support the underscore forms?
      • Could error on a new edition.
      • Scott: Doing on an edition boundary would work well with the new diagnostic system.
        • Can also be future-incompatible system.
    • Arlo: Should we make a list of all future breakage warnings, and discuss it next week.
      • Ed: If nobody does, I can.
      • Weihang: New contributor can help with researching the code history.
    • eric: Have there been any searches how popular it is?
      • ed: Not yet, but can do that.
      • eric: Saw 3 dev_dependencies on crates.io, didn't look further
    • eric: Proposal to error on the next edition, and warn on <=2021
    • ed: Is there an issue with MSRV?
      • Probably not? Likely supported all the way back.
    • rustin: Consider crates.io, parsing manifest itself, will investigate how its parsing will handle it.
    • weihang: Will check on deprecated issues/warnings
  • epage: nested packages
    • https://github.com/rust-lang/rfcs/pull/3452
    • Tobias wonders if its even worth it
    • Our feel and if there is a conflict between teams?
    • Ed: Expects this to have very little needs for the crates.io side.
    • arlo: Is it possible to publish a nested package to crates.io?
      • The RFC has some information about how that is specified, either in the dependency specification, or in the package itself.
    • arlo: Keep in mind the complexity of the learning curve for the module system.
    • ed: The impact on crates.io is related to parsing the manifest.
      • The features and dependencies and such of the nested packages get flattened into the parent, so that it appears as-if the nested don't exist. If crates.io is doing their own parsing, it would need to do that same flattening.
      • jacob: Would help with a better story for an official way to indicate how the publish normalization works and gets translated to an index entry. Documentation and/or code, not clear, but all third-party registries need to do this.
    • weihang: A consideration could be the upload size limit when projects start consolidating a lot of packages.
    • Scott: Another concern could be vendoring everything?
      • ed: Dependencies have to opt-in to being nested.
      • Might encourage vendoring things without upstreaming changes.
      • ed: Doesn't see this as a significant change, since users can today rename their dependencies and publish those.
    • Arlo: Could make the dependency graph less visible. cargo-sbom wouldn't be affected (?) but other tools might be.
    • scott: Thinks there are lots of benefits (proc-macros and such), makes that easier. But worries there are maybe some rough edges that could push against it. Leans positively overall, though.
    • jacob: Considering the documentation of the interaction with nested workspaces.
      • Will be good to give clear guidance on how to organize.
    • jacob: Not enthusiastic enough to dig in deep, but recognizes it has real motivations.
    • eric: Wonders if the Bezos meeting method would help with going over documents like this (30-minute read, then discuss).
      • Scott: Doesn't particularly like, needing time to consider it. Wants at least one day beforehand.
      • jacob: Doesn't love it, though recognizes it works in practice.
    • Put on agenda, but discuss on Zulip if we can.
  • scott: Question about code suggestions for diagnostics.
    • Whatever gets it shipping faster.
    • Not a hard requirement, would be nice in a future update.
    • Have made good progress on getting annotate-snippets closer to rustc, just a few cases left.

2024-03-12

  • epage: feedback on lockfile change reporting
    • zulip
    • How to avoid overwhelming users?
    • What might we want to do differently?
    • ​​​​1   1         Updating `dummy-registry` index
​​​​    2    +      Locked packages
​​​​    2    +      Adding dependency baz v0.0.1
​​​​2   3      Downloading crates ...
​​​​3   4       Downloaded baz v0.0.1 (registry `dummy-registry`)
​​​​4   5         Checking baz v0.0.1
​​​​5   6         Checking foo v0.0.1 [..]
​​​​6   7         Finished [..]
    • Weihang: Why only "adding", not change/remove?
      • Remove is only relevant to the sync case to update the lockfile to the manifest. It could be extra noise?
    • ed: Trying to be abbreviated to avoid overwhelming the user.
    • weihang: Can there be a sqlite db of the last recent updates, and report what was changed after the fact?
      • ed: This isn't intended for audit logging. One use case is to show when something is held back (which they might not be aware of). Also to be aware when the lockfile changes.
    • scott: Recommend talking to wg-diagnostics.
      • Showing adding/removed with green/red colors?
    • rustin: Why emphasize the packages not using the latest version?
      • ed: This comes from the msrv RFC, which is one way dependencies can be held back. Show awareness when this happens. Lets the user know what is happening so they can decide if they need to do something different (like change msrv).
    • rustin: Does it always display when using a non-latest version?
      • ed: Only when dependencies change.
      • One of the challenges of the "generating Cargo.lock from scratch", displaying a summary to try to
    • scott: Could this be a lint that could be turned off?
      • ed: Would like to see what this looks like, since concerned about it being verbose. A big focus here is to try to avoid being overwhelming.
      • Also, would this be a user-wide or project-wide setting?
    • jacob: This can be easily changed, so would like to move forward and iterate if we can improve it.
    • eric: Confused about whether it is behind verbose?
      • ed: Doesn't have verbose-specific output. Things have changed since the original.
      • eric: On new lockfile, only shows if not latest.
    • eric: Does it tell you why it is not latest?
      • ed: No. Only because of semver right now.
      • There is a lot of information that could be displayed, and that is hard to balance. Starting simple right now.
    • ed will move forward with working on the PR.
  • rustin: Start requiring a reason for all yanks issues#2608
    • Discussed it with the crates.io team again. The team thought it would be fine to put it in the index or the API. Size shouldn't be a particular concern. They want to try to add it as an experimental feature in the crates.io admin feature. Once we figure out how to use it within crates.io, we will consider introducing it as a feature available to regular users.
    • The team also agreed that we need machine-readable or other project-readable yanked message formats. But text should be a good start. More discussion is needed.
    • Not expecting too many yanked versions.
    • Milestones
      1. Admin panel (crates-io team only), work out UX
      2. cargo yank (post api), work out whether API is human readable or machine readable
      3. report in cargo commands (get api), work out whether content is human readable or machine readable
    • May need an RFC if it changes the index.
    • ed: Clarify machine-readable formats?
      • rustin: By having reason codes, the UI could show specific messages for these.
      • ed: Thinks there are challenges with the complexity of the user. Don't need to worry about this until we look at the yank api.
      • rustin: Will also need to consider when it goes in the index, how to handle machine-readable versus free-form text.
  • weihang: add http.insesure config once and for all
    • https://github.com/rust-lang/cargo/issues/13460
    • scott: Doesn't know how often this comes up. This is a footgun for doing something not correct. Allowing people to do something they may not want to do. Doesn't know why CA certs are available.
    • weihang: Have done this some times with virtual environments, where it can be difficult to get the networking configuration inside.
    • ed: If there is an escape hatch, would like to have a warning on every command to indicate it is insecure mode.
    • jacob: Could have insecure be a date, and if it is beyond yesterday, generate an error.
      • scott: Yea, similar to a "todo"
    • jacob: Maybe push back on this issue to figure out why the person can't configure their certificates. If they have a legitimate reason, or there are more people requesting it, then can consider some workaround.
    • weihang: Will ask them for more context and follow up with it.
    • eric: A little uneasy with adding this. However, recognizes lots of tools have this (npm, NODE_TLS_REJECT_UNAUTHORIZED, curl, etc.). Doesn't want to encourage people to do something they shouldn't. Wonders if this is because people don't know how to handle self-signed certificates (which require CA-signed certificates).
  • jacob: Discuss the merging of dependencies in resolution.

2024-03-05

  • epage: DST updates for calendar ics?
  • Checking permissions of meeting notes for hi-rustin
  • arlo: Unable to build in a repo with unsupported libgit2 features #10150.
    • Had to modify vendored build scripts.
    • weihang: How close cargo follow features in libgit2? Use ignore to handle .gitignore processing instead of libgit2.
    • ed: Can gitoxide handle this better, can we switch to that sooner?
      • arlo: Hasn't checked, but it probably doesn't handle this case.
      • weihang: gitoxide has the same issue as libgit2 where new features probably won't be adopted as quickly.
        • ed: Want to check with Byron.
      • josh: gitoxide does read split indexes.
      • arlo: There is another unsupported extension.
    • arlo: There are also global git configuration.
    • jacob: Does ignore handle global ignores?
    • eric: Just clarifying, the git scanning does more than just gitignore, it does staging checks as well.
    • arlo: Run current behavior, and have a fallback if it fails?
    • ed: Why is this related to a build script?
      • arlo: It enumerates all the files in the package to determine if a file has changed.
      • weihang proposed removing the "old style" build script support in a new edition.
    • josh: Agreed, would prefer to not have different behavior for publish.
    • scott: How tied should cargo should be to source control.
    • jacob: Fix the build.rs behavior so that if it fails the first time, ignore it and wait until the build script tells us what to run.
    • eric: Yea, the full scan in fingerprinting is a bug, but difficult to fix. Unfortunately, the other problem is that cargo doc always has to do a full scan because rustdoc does not provide dep-info files.
    • ed: Could there be a git-cli fallback?
      • arlo: A concern was performance, but doesn't know what it is.
      • josh: If it fall back only when libgit2 fails, and overtly said it failed and falling back to the CLI. Or make that configurable.
        • arlo: Would prefer a config.
    • weihang: Is it possible for libgit2 to ignore config it doesn't recognize?
      • ed: Or does gitoxide gracefully degrade?
    • eric: The big question is how likely is it for someone to have dirty repo, could they leak files they definitely don't want included.
    • arlo: Concerned about the CLI fallback, uncertain about listing all files.
      • eric: Does git cli have a command to list file status within a subdirectory?
        • Probably?
    • josh: If we add a config option, then it needs to be supported indefinitely. A (potentially noisy) fallback to the CLI would have the advantage that when gitoxide supports sufficient features, may not need the fallback.
    • scott: Does cap-lints handle cargo warnings?
      • ed: It depends on how you generate the warning.
    • cargo fix also scans for git status.
      • ed: Some of these cases could be a warning instead of a hard error.
    • Changing fingerprint behavior:
      • There were two suggestions:
        • Don't support old-style build scripts in a new edition.
        • Fix the fingerprint so that it doesn't unconditionally scan for new-style build scripts.
    • eric: Propose someone (arlo :) to spend a short amount of time to investigate if the git CLI fallback would be a small amount of code. If so, that seems like the best short-term solution.
      • arlo: Question on whether or not it should display a warning?
        • eric: Doesn't think a warning is necessary.
        • Josh: Does think it would be good to print something.
    • Weihang: Is there any security concerns of running the CLI?
      • eric: I'm not too worried about it.
    • arlo: Uneasy of running the git cli, are there other cirucumstances.
      • git gc runs automatically.
      • jacob: Could just use the net.git-fetch-with-cli config option.
    • arlo: Will investigate the cli fallback
      • Are we OK with issuing a cargo warning when it falls back.
        • eric: Another option is to put it under --verbose.
        • scott: May depend on how often it happens? How many people it affects.
  • epage: cross-platform regauth settings (https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/reg.20auth.20and.20libsecret)
    • Blocking my own adoption of regauth which I was going to use to check for any documentation updates that could help prepare for deprecating the reg auth default
    • Wanted to deprecate not having credential-providers set, and wants a single setup that works across machines, but cargo:libscret hard-fails if it isn't installed.
    • arlo: No good way to differentiate "someone wants to use this provider" and "ignore this provider if it isn't supported".
    • scott: Can you tag a target on the list?
      • ed: It is only libsecret. The other platform-specific ones just pass over.
    • eric: is that easy to fix?
      • arlo: yes, but need to decide which behavior.
    • ed: Could the unsupported providers' JSON API tell cargo that it wasn't supported because libsecret wasn't provided. Could it provide a message, and if nothing works, report those messages to the user.
      • josh: Likes the idea, display that if nothing worked.
      • arlo: The API does indicate it is unsupported.
      • ed: Would want to specify why something is unsupported (not implemented, today).
      • scott: Can there be an enum for the reason?
        • ed: Would like to have a free-form string to provide the reason.
        • arlo: Originally had a bunch of enum errors, but they weren't particularly useful.
    • Proposal: Extend the API to allow a provider to indicate it is unsupported with a message explaining why. If no provider works, then display each of the messages to the user.
      • This also includes "this provider didn't work because it didn't have the secret"
      • And possibly display those messages always with --verbose?
    • ed: Will look into this more, will consult with Arlo.
  • rustin: Start requiring a reason for all yanks issues#2608
    • Discussed it with the crates.io team. It just so happens that we need to implement it in the crates.io admin management feature as well. So the team had no problem with adding it.
    • Before I commit the rfc (and need to talk to Adam about how to move forward with this feature, as the work may overlap with his), there are a few questions I'd like to discuss first:
      1. should we put it in the index or send an http request to crates.io?
      2. what about other registries? Should we add this for crates.io only?
    • josh: Placing in the index should be fine for compatibility.
    • ed: The concern about the storing in the index is performance. This could balloon a significant amount.
      • Scott: Could limit the size? Could be a short reason that links to a larger reasons?
    • josh: crates.io could limit how long a reason is, and if it is too long recommend a URL.
      • scott: Was recommending having both a link, and short reason.
      • The link would just be displayed to the user if they want to read more.
    • ed: May be other areas where we need a separate database. Should yank-reasons be blocked on implementing that separate database?
      • jacob: Could deprecate yank entirely in favor of cargo-audit.
        • ed: There are strict limits in what fields that they support. But yea, rustsec database is the motivation for this.
        • "deprecated" and here's the replacement for it.
        • proc-macro back-compat crate future-incompatible warning.
    • eric: Doesn't necessarily think a separate yank database would be difficult to implement. If crates.io is already implementing it, then it just involves cargo providing the information to them, and possibly querying that information when needing to be displayed.
    • ed: There is also an argument about purity of the index, since the reason isn't required for resolution.
    • jacob: Could backfill the index if we decide to include it in the index in the future.
    • Include the reason in the yank API, let crates.io include it in the database and display it on the website, and then we could figure out how to display in cargo in the future.
    • jacob: The reason for just fetching the reason over HTTP is other indexes.
      • Could be an optional endpoint.
    • hi-rustin to continue discussions with crates.io team. We're happy to include the yank reason in cargo yank and the API. crates.io can display that if they want on the web UI. We'll need future discussions about how to display that in other cargo commands (like cargo install gives a warning). We could potentially have a new API endpoint for fetching the reason, but we'll need to consider back-compat with other registries (likely just ignore if the endpoint does not work).
      • There might be more discussion needed about the exact structure of the reason (is it a URL, a short message, a distinct reason, etc.)

2024-02-27

  • eric: Verify stabilization of Global cache data tracking https://github.com/rust-lang/cargo/pull/13492#issuecomment-1965180849
    • Conclusion: OK to move forward.
  • eric: What are the next steps of MSRV RFC?
    • Ed: No concerns raised by anyone on the cargo team, fine merging as-is.
      • The most obvious contention is "auto". Have time while doing the resolver-side to explore it, and pivot if needed.
      • Concerns around peeling the onion may not help, since it moves to another concern.
    • josh: Thinks most controversial will be cargo new setting "auto" the default.
      • Could add "auto", and then make a call later about changing cargo new.
      • Will likely still encounter people running into different use cases that they may have issues with.
      • Noting the degree of contrast between reliable workflows that we're working towards and "please just let me try, even if it might break". May be able to compromise with different options that allow ignoring rust-version constraints and seeing what happens. e.g. the recently discussed --ignore-rust-version-auto.
      • Reasonably hopeful.
    • scott: People are worried it is changing rust-version to mean "what I support" versus "what this was published with", and you don't know which one it is. Not concerned about it in the long run.
    • ed: cargo new is a UX command, and don't need RFC to change it. Very light two-way door.
    • jacob: pushback on "auto", but it is a critical part of the RFC, but I may not understand it well enough why it is so important (or why not defer it).
      • Josh: If auto were not present, would want to discuss the RFC a bit longer, but not opposed. The main rationale, with msrv resolver, potentially resolve to older versions, put that together that people want rust-version to be set so that they can accurately get things working correctly. Without rust-version set, you won't know what it works with, which hampers the resolver's ability to to work. However, rust-version is a chore to update. And if you fail to update it, you silently get old versions, which is probably not what you want. MSRV-enabled resolver plus rust-version = "auto" is essentially no change in the behavior of cargo. In the absence of "auto", would want to reconsider the default resolver behavior, but that would lose much of the value of the RFC (allowing the ecosystem to move forward while letting people who care about old MSRV just get od crates.)
      • Clarification: Not getting rust-version updated manually.
    • ed: Looks forward to have "auto" in cargo.
      • Only for the N-0 ones.
    • arlo: Would like to consider bikeshedding the "auto" name. Also concerned about the cargo new change.
      • Is there data about how many of the most popular crates is setting rust-version?
      • Jacob: 16%? Published since 2023?
      • arlo: Interested in usage
      • Can pull database to do queries.
        • Josh: xsv works well enough for querying.
      • arlo: I think that would help better understand how widespread the rust-version usage is.
      • jacob: Will update script to show that data.
      • Ed: feels like some people's perspectives are pessimistic about how people will use rust-version, and doesn't think that will necessarily be the outcome.
        • cargo new will inherit if used in a workspace.
        • Only affects publish.
        • Expects most popular dependencies will not use "auto", and thus won't be used everywhere. "auto" might be a signal about the maturity of the crate.
      • jacob: Could "auto" be a word that implies it should be changed.
        • ed: Wouldn't want to do that.
      • jacob: The data we are looking at assumes adopting msrv policy is hard, but that won't be true once the resolver is adopted. Things that are only doing latest stable might support older versions.
      • josh: Ed replaced "auto" with a placeholder in the RFC, and I'm wondering what you currently have in mind to replace it with?
        • ed: Something like "resolve-to-current-toolchain". "rustc", or "toolchain" might not be clear. Considering how the config will be laid out. "current" is another option.
        • josh: Likes picking the same token for the resolver behavior, and the name used in rust-version.
        • josh: Important to point out that not all use cases are equally supported. Sympathizes with trying to state that, because it produces strong reactions from people whose use cases expect to get subsidized by effort across the community.
    • scott: There's no way to see if "auto" is set in index. Slight concern, not a blocker. Would like for it to be considered.
      • ed: Can detect that in .crate via Cargo.toml.orig. Can backfill the index if necessary.
    • ed: Another common concern is around security, because if you are on an older version. Doesn't consider that to be a good proxy for security (for example, major semver changes). Would like to start conversations around cargo-audit to better handle that.
    • josh: Consider opening in the future, can we extend semver to have versions between every possible pair of versions, so if people want to do backports, they don't have to reserve room in the numbering scheme (e.g. 1.2.3 then 1.2.4, no space between).
    • Objections to merging as is?
      • ed: Make sure merge comment mentions some of the considerations brought up here.
      • jacob: Could strengthen it by putting that comment into the RFC. Mention "auto" is a placeholder. Give another 10 days?
        • arlo: Also likes to see it in the rfc text.
      • ed: Also wants to consider the edition deadline.
      • Conclusion: Will merge with comment explaining the considerations.
    • eric: There might be some disconnect about thinking the RFC is set in stone, and what flexibility there might be after it is approved.
      • ed: Would be good to have some clarification on the RFC process on what the flexibility is and what the process is after the RFC approved.
  • eric: Silently ignore cargo::rustc-check-cfg until stabilized: https://github.com/rust-lang/cargo/pull/13438
    • This build-script instruction was essentially ignored until 1.63, then it is an error on stable because it is "unstable". Since this only controls a lint, I don't think it should be too much of an issue to ignore it on stable.
    • Ok with merging and backporting to beta?
    • ed: The goal with the warning was to be MSRV friendly (that is, not an error, just a warning). The motivation to remove the warning is when using an older toolchain so you don't see the warning. Thinks it is important to be aware if you are using a toolchain where it doesn't work. Where do you make that transition between older toolchains and latest. Doesn't feel like it is worth it to change.
    • josh: Is there a warning to add missing things to their build script? For example, setting rustc-cfg?
      • ed: You won't see a warning for cfgs set that way. Cargo could potentially check that they are both in sync. But will see a warning if doing cfg!(...).
    • arlo: Proposes to merge as-is.
      • Warnings could hinder adoption of check-cfg.
    • ed: Should these still be issued more generally?
      • eric: Doesn't feel like there can be a blanket answer to that. Depends on the kind of feature. But also doesn't know for this example if there could be an absolute answer.
    • arlo: Had similar issues with registry auth.
      • Jacob: Made adoption a little more difficult.
    • ed: Probably fine with FCP staring, it is only a small window of what users we're focusing on.
    • Conclusion: Will go ahead and merge.

2024-02-20

  • weihang: cargo test --doc doesn't load shared libs
    • https://github.com/rust-lang/cargo/issues/8531
    • Zulip: dynamic linkers & mixed targets
    • 🤯 rustdoc --test does two things: compile and run tests.
      • proc-macro may load wrong shared libs when compiling doctest.
      • For cargo doc, proc-macro already has bug when loading shared libs, so this use case is perhaps unlikely to happen
    • 🤯 dynamic linkers may load dylibs built for a different platform and fail.
    • Conclusion: Ok to fix now without separating doctests build/run. Should be fine to just add to the path. Not a perfect solution, but should improve the situation.
  • crates.io: tell them we're in CI or add other metrics (OS?)
    • https://github.com/rust-lang/crates.io/issues/2886
    • Mainly around download counts. Include something in user-agent or somewhere to tell it is in CI.
    • Other metrics? OS?
    • Scott: Not all CI providers set CI
      • Ed: Original asking for other env vars, but CI should cover 90% of downloads.
    • ed: What are you wanting to measure? Human interactions? Distributions?
      • Fine with leaving the policy up to crates.io.
    • Jacob: Was able to avoid contributing to metrics by going directly to the S3 bucket/CDN, but that is going away.
    • Josh: The first case of intentionally making CI different. Decreases potential for CI to be identical than other environments.
      • Scott: Could have an opt-out?
      • Ed: Could have "registry turn off all reporting".
      • Jacob: What defines "all reporting"? Can't promise to remove all trackable information.
    • Arlo: Would like to see more clarity around user-agent? What happens if the user overrides it? Survey of common CI providers (like top-5 if it works).
    • Scott: Difference between "CI" and automated systems.
      • Ed: Focus more on this one setting, and let crates.io focus on how to best report it.
    • Josh: Good with limiting what cargo checks (like just CI).
    • Weihang: Do we need to inform the user?
      • Arlo: Doesn't feel like it is anything serious, similar to compression types.
      • Josh: Agrees it is innocuous, but still capable of being tracked.
    • Jacob: Would be good to get the reasoning.
    • eric: Unclear about the reasoning for not counting CI.
      • Scott: Can be helpful for making decisions on things that are separate of CI jobs. Would be better to track both, and allow filtering.
      • Arlo: Also suggests tracking both.
      • Josh: Impression that they will track both.
      • Jacob: Would be good to have written team response.
    • Jacob: Knowing CI could be useful for something like caching decisions.
      • Josh: That can be determined from IP addresses.
      • Jacob: The IP only tells us it comes from a certain facility, but not what it was for.
    • Conclusion: Eric will respond on the issue to ask for some more information.
  • Josh: Warn on lack of edition?
    • https://internals.rust-lang.org/t/idea-rustc-cargo-should-warn-on-unspecified-edition/20309
    • If you don't specify the edition, that is usually a mistake.
    • Can set "2015" to disable the warning.
    • Jacob: There are series of cargo versions that don't allow you to set edition.
    • Ed: Could control the warning based on rust-version.
    • Josh: rustc behavior is not our problem.
    • eric: Uses rustc directly, and a warning would be annoying.
      • There's uncertainty if people who run rustc directly are people who know what their doing, or not.
    • Ed: All for the warning if edition is not set in Cargo.toml. (and also always pass --edition to rustc in all cases)
    • Weihang: Where is it displayed?
      • Ed: Probably at the start.
      • There is a tension between whether or not users look at the first error or the last.
    • Josh: Be cautious in cases where someone is doing something reasonable, but good to steer people when they are off the path.
    • Conclusion: Ed is working on a patch to add the warning.
  • weihang: Rename Config to GlobalContext
    • https://github.com/rust-lang/cargo/pull/13409
    • ed: Lesson learn: Focus on keeping the scope of the change as small as possible, land it more quickly.
    • eric: Asks to update PR title and description for the final names.
    • Scott: There were some minor issues with names not getting renamed correctly.
    • Weihang: Also wants to avoid merge conflicts.
  • ed: Snapbox tests to include svg renderings
    • ehuss: Very minor observation that it seemed like there were a lot of blank ones, not sure if it is possible to infer if it isn't there that it is blank?
      • Ed: Can probably do that.
    • Arlo: Could symlink, but concern on things like Windows if we aren't already using symlinks.
    • Arlo: Really nice to avoid the "please post a screenshot in the PR" case.
    • Conclusion: No objections to moving forward.
  • Scott: Reminder to look at devtools council representative selection in Zulip.
  • Eric: Reminder for query of ideas for funding from the Foundation.
    • Ed: Really liked the in-person support.
  • Jacob: Having discussions about MSRV resolver support with weihang.

2024-02-13

  • weihang: 🎡🛝🎢🎠🎆🐊
  • epage: Should we make cargo clippy the linter for Cargo.toml? Should we merge it into cargo for access to all of our existing logic?
    • Why a separate lint command: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Cargo.20Lints/near/396907703
    • A list of lints (without thought on whether they go in cargo or cargo clippy): https://github.com/rust-lang/cargo/issues/12235
    • flip seems on board, sounds like when clippy went out of preview, it was the Cargo Team that blocked it before
    • scott: Seems like it could help in the long run.
    • josh: Seems like a good idea. Not sure if clippy is where all lints would go. Seems good to put more opinionated lints there.
    • scott: also wants cargo fmt for formatting Cargo.toml.
    • ed: This is more about making it easier to add and experiment on lints.
    • eric: why not make these allow-by-default?
    • jacob: Original discussions around using clippy itself, concerns around backwards compatibility.
    • ed: Being an explicit linter gives more flexibility for experimental lints.
    • jacob: Would we want to encourage those kinds of PRs to our repo? Or others?
    • scott: The ability to "preview" lints.
      • Not much of a culture change of a nursery of broken lints to be added to cargo?
        • ed: That seems like a large culture to me. (having "preview" lints).
    • jacob: Where the code lives, the cargo team should support it (cargo::).
      • ed: Also sees how you access it being important.
    • ed: several stages: moving lints into cargo clippy, and moving cargo-clippy into the cargo repo.
    • ed: Can we focus on just moving the command?
      • Primarily moving this: https://github.com/rust-lang/rust-clippy/blob/master/src/main.rs
      • eric: There were several concerns in the original decision.
      • Motivations
        • Concern: Taking on other teams subcommands
        • Not wanting to make using clippy a requirement for getting cargo lints
        • Dealing with driver not present
      • If reason is to make the command better then it admits defeat for improving other commands
        • ed: Feels clippy is used well enough to motivate over other subcommands.
    • scott: sees cargo clippy being a way to get nursery-style lints for cargo. Primarily an interface for running some lints.
  • Funding for git2-rs - how should we handle it?
    • https://github.com/rust-lang/git2-rs/issues/999
    • Donate to gitoxide instead (as long-term replacement)?
    • Fund maintainer of git2-rs?
    • Do we need to check with the Council? If so, we should approach it as "Here's what we intend to do with this, is there some objection".

2024-02-06

  • epage: --check-cfg
    • Looking at draft of stabilization report
    • One concern is number of warnings if this is unconditionally enabled
    • We are looking to solve the --cfg docsrs problem (solved)
    • They might do a crater run where they turn it into an error to see how much of a problem this is (running: https://github.com/rust-lang/rust/issues/120701)
    • Mostly wanting to check in for the part that might affect rustc's stabilization report to avoid back and forths when this is brought forward: if we deem it "bad enough" (e.g. like public dependencies), would we want it allow -> warn on Edition boundary or one of the other listed options?
    • Any concerns on the cargo side about the rustc stabilization?
    • Lang team is somewhat against edition-specific warning.
    • Weihang: Will affect fingerprint detection?
      • Ed: Already handled.
    • Arlo: Concerns about crates with a large number of features?
      • crates.io has a limit of 500, but some crates can have exceptions.
      • Features get passed as a single argument. There is a serialization cost. Might cause a spill to an arguments file.
      • Is this cost paid by the library as a dependency?
        • Yes.
        • Can we tie it to cap-lints?
      • eric: Would like to see it measured to see if it matters.
        • eric: Thinks it would be fine to disable for non-local.
        • ed: Every once in a while, there is a need to see dependency warnings like for clippy unsafe (with -vv), but probably not
        • Decision will make it local only.
    • eric: What's the plan for handling key-checking?
      • ed: Main workaround is to add the cfg syntax to RUSTFLAGS.
      • RUSTFLAGS="--cfg tokio_unstable" was changed so the lint doesn't check the command line.
    • We are appreciative of all the work Urgau has done.
    • Weihang: Do a call for testing on TWiR or somewhere?
      • ed: Sounds good.
      • Decision Do a call for testing.
    • Ed: Stabilization report will call out the previous concern about RUSTFLAGS.
    • action
      • measure performance of windows
      • call for testing
      • local only
  • eric: Fine-grained index cache cleaning.
    • Should the index cache last-use data, and delete old cache entries? Current disk usage is about 100-200MB for crates.io, and it doesn't ever shrink.
    • ed: Unconcerned about the overall size usage, and the overall bookkeeping.
    • ed: Wonders if it can leverage the .crate tracking.
      • eric: Possible, but it would need to change the meaning, since you can query without having a .crate..
    • Jacob: What is the easiest short-term solution?
      • eric: Not changing anything.
    • Scott: Also doesn't have a concern on the disk usage. Perhaps have a long-term plan.
    • eric: Follow-up, should we turn it on now? Seems unlikely we will learn anything in the next few months.
      • Weihang: Expose less configuration when stabilizing?
      • Just stabilizing the tracking (without cleaning), allows older versions of cargo to work better.
    • Scott: Wishes we had the ability to do perf testing across a variety of different hardware.
      • Jacob: Emulating slower systems probably won't get realistic results.
      • Scott: Has some machines that can be used for benchmarking.
    • Weihang: What is the stabilization of the schema?
      • eric: No intention that it is stabilized for any other tool. Only has to be compatible with older versions of cargo.
      • weihang: Can we explicitly call it out?
        • Can the schema be extracted as a constant, and a doc comment not to depend on it.
        • jacob: Change the name of the tables to say it is cargo_implementation_detail?
          • And if we want to ever make it stable and exposed, can change the name.
    • eric will look at a more concrete stabilization proposal (of tracking only).
  • epage: MSRV RFC
    • Please come to me if you have questions.
    • Scott: Would like to take public comments into account.
  • Scott: Using Config as a global context.
    • eric: Seems fine, thinks it can be renamed if that helps.
    • ed: Can use type alias to help partial migration.
    • ed: ctx seems fine, used elsewhere.

2024-01-30

  • josh: Delegate Cargo.toml style guide to style team?
    • https://github.com/rust-lang/cargo/issues/13313
    • Now waiting for style team to update based on feedback.
    • The style team doesn't decide how the tools actually apply the formatting (like how cargo fmt versus rustfmt works). Rustfmt team has an expectation that they have the expectation they will do it, would be good to reach out to them to discuss.
    • Ed: For the cargo team to take on formatting in cargo fmt, cargo-fmt (the subcommand) would need to move to the cargo repo.
    • Scott: With subcommands like cargo fmt and cargo clippy in the cargo repo, the cargo team can then implement cargo-specific behaviors within the subcommand.
    • Josh: Makes sense it would be good to have formatting support in the cargo side to handle other subcommands like cargo add or cargo update, which may need to do canonical formatting, too.
    • Ed: Considers cargo-fmt in the cargo repo a lower priority, doesn't feel like pushing for that.
    • Ed and Josh: cargo clippy subcommand in cargo repo does make more sense since there are more actions that could be done by cargo (cargo-specific lints, avoiding duplicate work, etc.)
    • Ed: As we add new fields to Cargo.toml, what is the process to get the style guide updated with the style team?
      • Josh: If the style team drives the style, (most additions probably don't need changes), nominate the issue for the style team to put it on their agenda, and they will decide the best way to format it, and will send a PR to the style guide to update it.
      • Ed: Would stabilization be blocked getting into cargo fmt?
      • Josh: Lang changes are blocked. If we wanted to make the same decision, we could. Usually changes will get prioritized to be done fast enough to avoid blocking others.
      • Ed: How much of an issue this will be will depend on how prescriptive the style guide is on all the specifics.
      • Josh: Expects that only a small number of fields will have a defined order, and generally everything else will be sorted order. So generally, doesn't expect there to be many changes to typical manifests.
      • Eric: Does changing the sorting order of an entire file constitute a major overhaul?
        • Josh: Since the current style prescribes a sorted order (and things like cargo add handle that), for most it shouldn't be a major change.
      • Scott: Would like package.workspace to be up towards the top.
      • Josh: Delegation isn't irrevocable, if the style team isn't supporting what generally the cargo team wants, then we can revisit it. Not necessarily individual changes (since everyone is going to have small differences of opinion), but if there is a large overall difference.
  • epage: retro on XDG

2024-01-23

  • epage: https://github.com/rust-lang/rfcs/pull/3537
    • package.rust-version = "auto"
      • auto or current or toolchain
      • Arlo: Likes "current" over "auto". Auto could be interpreted as "figure out the best value".
      • Ed: What does the term "support" mean? There is syntactic support, but also the logical support that the project adheres to.
      • Jacob: Caveat with "current": Another algorithm could be "go look at index data" and it tells you what the current stable is. That is, "current" could mean what the latest stable is, versus what the user is currently running on.
        • ed: "Stable" is even worse.
          • Arlo: Yea, that seems like "go figure out what stable means".
      • scott: Is there a better word for "whatever I'm currently using"?
        • Current? Local?
        • ed: Local seems a little weird, since it implies more than what the field is intending.
      • Jacob: Could the RFC use a non-bikeshed name like "the-rust-im-currently-using"? And then resolve it later?
      • Conclusion: Mark it as an unresolved thing in the RFC, and not block on it.
      • weihang: "unspecified" is another option.
      • eric: Question about using "auto" with cargo new.
        • ed: The quality of the msrv resolver depends on the information available. This helps raise awareness of its existence, and gets more data in the index.
        • arlo: What about not setting during cargo new, but requiring it in cargo publish.
          • ed: There are some use cases where some users intentionally don't want it set.
        • scott: Possibly could warn on first-time cargo sees something that needs explaining or attention? "This project defaulted to auto, here's the reason…" cargo publish could display a warning if you are doing something odd.
          • ed: If it is a warning, it is too late, it is already published.
        • ed: Setting rust-version on cargo new could easily go stale.
        • arlo: Adding fields to cargo new has a high bar.
          • ed: Reasoning is that the bar for cargo new is low it is an interactive workflow, and we expect the user to modify it to publish.
          • Scott: Can there be a comment explaining it?
          • ed: Doesn't like comments in the default template.
        • eric: Just had some vague uncertainties about it, wasn't a specific concern.
    • Jacob: A struggle to keep up on RFC discussions. Apologizes for not being more involved.
      • ed: Struggling with what appears people skimming, and missing some aspect.
    • Jacob: Some arguments for doing minimum versions are getting stronger.
    • ed: A lot of this is what is meant by "support" (targeting, versus supporting).
    • --ignore-rust-version on build commands
      • Apply to resolution as well as the build failure?
      • Since passing it in on every invocation is prohibitive, it seems fine
      • This means that cargo check --ignore-rust-version, it ignores both rust-version errors, and gets latest dependencies.
        • That should be ok, since this is mostly a one-off flag.
      • Arlo: If I use this flag, does it rewrite the lock file?
        • ed: no
      • Arlo: If Cargo.toml is modified?
        • ed: Anything that needs to be newly resolved will be affected, but others will stay locked.
      • Scott: Is there a way to update lock file without manifest?
        • ed: cargo update
        • ed: cargo update will also get --ignore-rust-version
        • scott: Can there be an --incompatible alias?
          • ed: That is meant to mean something else, and may change in the future.
        • scott: Good to have that flag wherever you need it.
      • Weihang: What if running cargo fix, and editing Cargo.toml, would it fix the rust-version?
        • --ignore-rust-version could have a scope of what it should ignore (ignore compilation versus resolution).
        • ed: Restating: If cargo emits a warning with a suggested fix, that would be tied to a specific version, and cargo fix would apply it without respecting msrv?
        • ed: there is a related clippy lint that has interaction with --ignore-rust-version.
        • weihang: it would be helpful to specifically define the scope of the flag.
      • scott: Could recommend CI job to run cargo update and check if anything is out of date.
        • That would fail a lot.
      • ed: The RFC says there could be warnings to indicate what is outdated (possibly on any command?).
        • Jacob: Could also be appropriate to have warnings about yank?
      • ed: In the future, could hide the --ignore-rust-version on build commands, since it won't be needed as much.
      • In summary, the concern is around the flag now having two actions, and should that be decoupled or any other question.
      • If there are more questions, please follow up with ed.
  • epage: home: reduce MSRV to 1.64
    • https://github.com/rust-lang/cargo/pull/13270
    • djc has offered to help with maintaining.
    • ed: Doesn't see the user value for this, the user still needs to do manual updates.
    • ed: Concern around how this would impact the development within the cargo workspace.
    • Should the focus be on the ACP?
    • Jacob: Not that long ago, cargo only supported stable. Now we are doing N-2.
    • Rustin: What is ACP?
      • API Change Proposal with the libs team. The proposal is to change the home() function in the standard library to undeprecate it. djc said they would get to it soon, but it has been a long while.
    • Weihang:
      • home crate is used by a lot of people.
      • People may be stuck on an old Rust version.
      • home is not tied to cargo's release process. Maybe we could do something more special to it.
    • ed: Could split it out of the workspace, or even split it out of the repo.
    • jacob: 1.64 is pretty old, that seems like an absolutist approach.
    • Arlo: Sees an argument for treating home as different.
      • ed: This is mainly to help with dependency resolution, so you don't have to manually run cargo update --precise.
    • Weihang: Propose use 1.64, there might be more people than we thought. It may be difficult for more people to do manual resolution. If it doesn't add too much burden on us.
      • ed: This means we can't use new features in our workspace.
    • Jacob: Compromise to double the msrv (N-4), along with a display of work along ACP.
    • ed: Will follow up with N-4 proposal with agreement to move forward on ACP.
  • Scott: Still working on splitting up the calendar invite.

2024-01-16

  • Josh: edition as an integer.
    • Very bike-sheddable.
    • Josh: How do people feel about doing this?
    • Scott: Gone from meh to no.
      • Concern over error messages and implementation complexity.
      • A "breaking change" that some people were mentioning.
        • A change as in an MSRV bump, and tools with their own parsers will need to be bumped.
      • Seems like a lot of work for removing two characters.
    • Jacob: The benefits seem small in comparison to the costs.
    • Arlo: Also leaning from meh to no.
    • Josh: Should we FCP close it?
    • Scott: Semantic difference of a number versus a year/edition.
    • Arlo: Is the error message bad, and is there an issue tracking that?
      • Scott: Unsure, but the error messages should be getting cleaned up with diagnostic work.
      • Ed: Will double check on what it looks like.
      • Jacob: A test might help ensure the error message doesn't regress.
    • Josh will write a comment to close the issue.
  • epage: Turn off, rather than error, if public is used on stable?
    • This was proposed in the RFC if we used a different name
    • Unsure what the timeline to stabilization will be due to compiler bits
    • If we change this now, we widen the window of when people can use it without affecting MSRV
    • https://github.com/rust-lang/rust/issues/44663#issuecomment-1888356071
    • Today: public=true generates an error because it is unstable.
    • Should we turn it into a warning now, this allows avoid MSRV bump from that point forward?
    • Jacob: The old RFC had specifically different behavior in the resolver, and ignoring it would be broken. In the new RFC, it isn't quite so clear that it is different, it is only generating a warning.
    • Ed: Made sure that parsing only generates a warning if the TOML fails to parse.
    • Jacob: Does seem like it would be better to be a warning.
    • Ed: Regarding case-by-case handling of error vs warning, would be good to document how to make a decision.
    • Ed: Only example of not requiring an MSRV was lints and package.rust-version.
    • Scott: Related to topic of building things locally versus when they are published.
      • Ed: Does the MSRV apply to local development? See the MSRV RFC.
        • BTW, the MSRV RFC should be ready to look at.
    • Decision: Make public ignored on stable.
    • Scott: Leaned towards keeping it an error, natural instinct, but understands not.
      • Doesn't seem like there will be very many versions between now and when it will get stabilized. A small window.
      • Ed: Concern over risk of this feature not making the edition. There isn't anyone stepping up to do the compiler work.
  • epage: lockfile for cargo publish's verify step
    • https://internals.rust-lang.org/t/pre-rfc-msrv-aware-resolver/19871/65?u=epage
    • We only include Cargo.lock if bins/examples present
    • This breaks down when people publish using MSRV
    • Options
      • Include Cargo.lock as a statement of what was verified, fixing this is a side effect
      • Prefer verifying with existing lockfile
      • Prefer verifying with latest and tell the user to upgrade (ie "do dev on latest even if you support older")
      • Prefer verifying with latest but allow overriding with MSRV aware resolver
      • Extend the MSRV-aware resolver RFC change to cargo publish (which we'll need to distinguish from cargo install as they are both ephemeral)
    • Wants to record at the time of publish what was used.
    • Possible MSRV failure if not using the latest toolchain.
    • Arlo: Didn't know Cargo.lock wasn't included if no bins.
    • The Cargo.lock will be a mostly meaningless file in the .crate file. A larger impact is the cargo publish verify step using a different set of dependencies.
    • eric: The reasoning was so that it would verify what users would experience if they use your package.
    • Jacob: Should verify use the installed version?
    • ed: Will create an issue to continuing to discuss it: https://github.com/rust-lang/cargo/issues/13306
  • epage: Guillaume asking about https://github.com/rust-lang/cargo/issues/11036
    • cargo install ignores the rust-toolchain.toml or uses the wrong one
    • If there is a single-team solution we are okay with, they are up for implementing it
    • Says they will post a blog post explaining their setup.
    • Jacob: Argument against this is abstraction barriers (weak argument), cargo doesn't know it is being run in a wrapper. How is cargo supposed to know which toolchain manager it is being used.
      • Ed: Cargo does have some optional support for rustup (error messages, performance optimization).
      • Jacob: Example: Install rust/cargo from debian, then cargo install something that has a toolchain file, what should cargo do?
      • Ed: Wonders about pulling rustup's toolchain lookup logic into a library.
      • josh: The normal way to handle debian case, common way is to make things conditional, verify what you are supposed to be using, and error if not.
      • Scott: Likes the idea of sharing logic between projects.
      • Arlo: Cargo could detect the rust-toolchain file, and display an error or warning if it is detected.
      • Jacob: If the toolchain file got more complex, like specifying the toolchain to use for install could cause an issue. Older cargos would misinterpret the meaning of the rust-toolchain file.
      • Arlo: Automatically installing the toolchain when rust-toolchain is detected seems kinda scary.
      • Jacob: Concern over security. path toolchains still require something locally installed, but still can impact the security considerations.
    • Ed: cargo install will limit config loading to $CAGO_HOME (except with --path).
    • Rustin: Does it make sense for rustup to auto-install?
    • Ed: Restrict this to --path, seems less scary since you already have it local, and it wouldn't be any different from running cargo install --path ..
    • Scott: Concern over installing older versions.
      • Ed: That's the primary use case.
    • Ed: Seems like there is interest in at least having message to warn the user about the scenario. Will follow up on the issue.
  • Rustin: FYI, crates.io has added a limit of 500 dependencies.
    • Scott: Can cargo limit this?
      • Ed: Probably not, crates.io has per-user limits, and other registries may have their own policies.

2024-01-09

  • rustin: cargo information
    • Reporting information from crates.io: https://github.com/hi-rustin/cargo-information/issues/20
    • Download counts, last updated
    • Requires an API
    • They said it is OK, it is not too expensive to access this information.
    • Does that make sense for the command to fetch this information in this way. In particular, what is the relationship between crates.io and other registries.
    • ed: Background: Is this the crate I am looking for? how do I evaluate this is the crate I want?
      • More likely to be used with crates.io than something like a closed corporate registry.
      • Could document this as an optional endpoint a registry could implement.
    • Jacob: How would another registry opt-in to this? What would happen if crates.io changes the data they collect? Registries could change the metrics they collect over time.
    • Jacob: For crates.io, have a separate endpoint for the front-end versus cargo.
    • ed: May be a little over-engineered. This is a UX feature. As long as older versions can gracefully degrade. (Maybe log deserialization issues.) Ignore endpoint failures.
    • Jacob: The documentation should indicate that endpoint and fields are optional. The endpoint should have a URL field, that tells the user where they can go via a browser to get more information.
      • ed: URL link could be useful for more information like the security tab.
    • arlo: Would be good for this to take source replacement into consideration.
    • josh: If cargo info has something like a JSON output, it could embed the full response from the endpoint.
      • ed: And documented that this is free-form.
    • Arlo: Concern that people could use a JSON API to get information about all of their dependencies, which could hit rate limits.
    • Rustin: Currently only interested in download counts and last updated.
    • ed: If there is a JSON output, don't reproduce the API endpoint data, instead just return the information we collect without that endpoint. Just tell the user how to get that information themselves.
    • Currently no implementation or plan for a JSON output in cargo information.
    • Arlo: Would it make sense for crates.io to have a separate endpoint that only has the minimum information that is needed.
      • rustin: hasn't asked crates.io for that, yet.
    • jacob: At some point, it might make sense to not download the .crate file to just get the Cargo.toml. This is a problem for PyPi right now. How in the future, can we extend the download endpoint to support that?
      • ed: Currently the .crate file is needed for things like implied bin paths.
      • jacob: Consider the costs of the extra download stuff.
      • ed: PyPi's issue is maybe more related to them not having an index at all.
      • jacob: Doesn't need to be done now, but should consider how this can be handled in the future.
      • weihang: Filling in all the information in the published Cargo.toml could help with Docker caching issue, too.
      • jacob: The registry could be responsible for collecting all the information at the endpoint that is needed.
      • arlo: Recalls a similar concern about debugger with sourcelink (windows source server), where it would be nice to ask cargo/registry how to access a specific file.
        • Would be good to also be supported in mirrors of registries.
        • Great for going on different (non-development) machines to be able to debug things.
    • rustin: Should I use some dependency for accessing crates.io API? For just one endpoint?
      • Arlo: Consider using the crates-io crate?
        • ed: Yea, that is intended as a general-purpose library for accessing any registry.
  • Scott: Other teams have set up a shared calendar: https://github.com/rust-lang/calendar-generation / https://github.com/rust-lang/calendar
    • jacob: Yes, if there is an official way to do this, we should do it.
    • sounds like Scott volunteered to set it up. :)
  • ed: https://github.com/rust-lang/rfcs/pull/2887 — Allow specifying dependencies for individual artifacts
    • Considering the difference of multiple bins in one package versus using multiple packages.
    • If we make a decision on that, then we can close out several stuff.
    • People like the low-overhead of tossing a bin into a package versus creating a whole new one.
      • But this increases the complexity/overhead of individual packages.
    • scott: With grouped inheritance, that would allow a bad templating system that would help make it easier to have multiple packages. Easy to grab dependencies needed for a binary.
    • josh: Maybe not have dependencies per binary, but allow binaries to specify the features they need.
      • ed: Eric had an RFC for that, but that had issues with feature unification, which particularly makes testing more difficult.
      • ed: An alternative on the prior RFC is to only enable when explicitly specified for --bin.
        • josh: Also a question on what cargo install does, does it require specifying the specific binaries to enable?
    • https://blog.rust-lang.org/inside-rust/2024/01/03/this-development-cycle-in-cargo-1-76.html#lints-redux touched on how workspace inheritance could group.
    • jacob: There is a deadzone between "just add a bin" and "add a new package".
    • josh: Can make either of those sides easier.
    • ed: There are different kinds of binaries. Some are more like helpers involved with the package itself versus binaries that are for users.
      • If things aren't tightly coupled, they should be in separate packages.
      • Because we are not providing much guidance, it is difficult for people to know how to set things up.
    • jacob: Struggles with setting up workspaces. To use them, you actually have to learn how they work.
      • Would be nice to have a cargo add-like command that would make it easier to transition to a workspace and create a new package.
      • Ed: Sees a similar thing to cargo-script, where there is a "scale up" step, where you need to graduate to a more complex setup.
    • weihang: Remove the "target" support, and only use workspaces? This is a thought experiment of what is missing for workspaces.
      • Overhead: create workspace, need Cargo.toml, src/main.rs, publish more complex
        • Workspace support for cargo scripts would help?
      • Naming: foo + foo-cli and cargo install pain with it
    • rustin: In Go, put almost all the binaries in a cmd directory. Main files are in different directories. go build to the path of the binary to build. Utilities for removing unused dependencies. Example is Kuburnetes, which has ~20 binaries, and you can just specify which ones to build.
    • josh: Fan of making workspaces easier to use. Nice to have commands to convert. In some common cases, use a cargo-script like approach, where those can specify their dependencies.
    • scott: Feels like having tools to expand into a workspace would be useful.
    • ed: A solid middle-ground use-case: pulldown-cmark has a binary that is a CLI wrapper around the library. Unfortunately the CLI is enabled by default, which requires default-features=false.
    • ed: Another workflow issue is the naming issue. cargo install foo where they want "foo" to be a well-known name for their package, which is used for both the lib and bin.
      • Need to know cargo install foo-cli is annoying.
      • Needs steps to ensure binary name is correct
      • User confusion over tool / package name
      • josh: Knows several projects have run into this issue of wanting to use a single name for both.
      • arlo: What happens if you have cargo install, and there is a required feature?
        • An error if there are no binaries with the requisite required-features.
        • If that wasn't an error, it seems like that could help a lot of use cases.
      • ed: If the bin becomes too big, people push most of the code into the lib. But the library doesn't have the same kind of stability (because it is only focused on supporting the binary itself). This is done for some things like support doctests, which don't work with a bin. Almost want three kinds of "units" involved (a public API library, and private-API library for the binary, and the binary itself).
    • jacob: A sample tool for migrating to a workspace doesn't have to be first-party.

2024-01-02

  • epage: build scripts and target config
    • See https://github.com/rust-lang/cargo/issues/13211
    • Are we ok with moving forward with cargo:: syntax without a similar compatibility fix for target config?
    • Ed: Fine with moving forward, bar for config is a little bit lower.
    • Arlo: Thinks we need to be careful moving forward that we don't have similar situations in the future.
    • Scott: Do we need to stabilized sooner rather than later?
      • Ed: Not especially, but it blocks stabilizing something like the error directive.
      • Scott: Would like things to be settled before stabilizing.
      • Ed: Is uncertain if that these two necessarily need to be linked, since they can be possibly resolved independently.
      • Josh: Only thinks that it would be nice to be consistent, but not significant. Probably doesn't even block error (who would set it?), but could block other directives.
      • Ed: Mainly that new directives would be blocked by fixing config.
      • Josh: In theory, we could have moved away from cargo:, in an edition. But the config doesn't have an edition equivalent. Not obvious how we migrate config to allow introducing new directives that might conflict in config. Can do design asynchronously though.
    • Decision: No concern with moving forward.
  • Scott: better way to have more visibility to meeting notes?
    • Better way of showing people what we have discussed. Ed is working on a blog post that does something similar.
    • Jacob: See how Ed's blog post goes and figure out how to move forward after that?
  • epage: What can be associated with an Edition?
    • Defaulting to MSRV-aware resolver would require a non-migratable CI change for a small subset of Rust users (who likely are advanced users who are "in the know" with Rust releases)
    • We would need a big splash for the release that makes that change to ensure people to update if their projects need it
    • Not migrateable but low enough impact that we could likely do it
    • Edition changes are generally opt-in but that would require a workspace edition field which we don't have
    • Maybe resolver = "3"?
      • And default change in edition.
    • Ed: Thinks breakage should be very minor. Some corner cases with how some people were doing latest testing in CI.
    • Not an issue to support both behaviors.
    • Jacob: One thing that isn't user config, is that "this project's policy".
      • Ed: There's enough different scenarios. Not necessarily never put something in the manifest, just doesn't want to block on that.
    • Arlo: How does edition work in a workspace? It can only be inherited in the [package]. Still isn't global.
      • Is there a warning about mixed editions and the resolver field? There is a warning for virtual workspaces without a resolver.
    • eric: resolver="3" sounds good, and changing that default in 2024 also sounds good.
  • Josh: Solution for features with fallback dependencies that should only be enabled when the feature is disabled? (e.g. flate2 wanting miniz_oxide if and only if another zlib is not enabled.)
    • We've talked about long-term plans for mutually exclusive features or key-value features. A design for that could solve this problem. But do we need to go that far to handle this case?
    • epage: issue for this https://github.com/rust-lang/cargo/issues/1839
    • eric: Clarification: for flate2, if there are two backends enabled, like zlib-ng and miniz_oxide, it just picks zlib-ng, and miniz_oxide is built but ignored, which is the problem.
    • ed: When there are more than two choices, things break down and mutually exclusive features would be a solution.
      • Josh: Or key-value, where the value is an enum of the set of things you want to support.
    • Josh: Is there a smaller solution to something like target cfg syntax that can address a narrower set of issues?
      • How complicated is it in the resolver?
      • Jacob: At what layer of resolution is this being done? If at the input layer, resolution is not affected.
      • Ed: When looking at a package, have features already been unified?
        • Jacob: Not really. Other dependencies added in the future would add new features. And if that removed a dependency, then that would be an issue, the resolver can't really handle that.
        • Could cause cycles.
          • (Particularly with dev-dependencies.)
    • Josh: Would mutually exclusive or key/value features solve this?
      • Possibly?
      • Jacob: Could be done in feature resolution pass?
        • Josh: That would be fine. Ok if in the lock file.
        • Jacob: Some people don't like having unused dependencies in their lock file, vendoring, etc.
    • Jacob: It would be feasible to have platform pruning in the resolver, if you tell it which platforms you want to support.
    • epage: https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618
      • Josh: It was maybe not clear that it is wanted to have someone else take it on, that it wouldn't be posted as an RFC.
        • There was a statement near the top, but it said not to have time to see it through.
    • eric: How does mutually exclusive relate to key/value?
      • Ed: Most of the use cases were application-level decisions, and unification wouldn't work with key/value.
    • Ed: The main wrinkle is making it per-package, and how to specify an exact package, and if you upgrade, how does that break things.
    • Josh: Simpler to move forward with global control of the features of one crate, and then a later step to have "public" features that a crate exposes features that other things are able to look at and condition on.
    • Josh: What is the possibility of Ed working on it?
      • Ed: Probably not in the foreseeable future.
    • ed: rust-version in cfg() syntax, can be used for things like polyfills. Would be nice to support that in dependency declarations. cfg-accessible wouldn't have the same support at the cargo level.
      • Jacob: How does the lock file handle this?
        • Ed: Lock file doesn't handle this, more like the post-feature pruning.
      • Josh: Could build build-dependencies, and then have build-script emit features for a crate, and then let the resolver take that information.
        • Jacob: At least three issues with that. N resolutions. That could cause divergent resolution between dev-dependencies and what was picked afterwards.
        • Josh: Could just accept that dev-dependencies can resolve with a different set. Alternatively complain if they can't be unified.
        • Josh: Would be able to have significantly more power to specify which features are used.
          • Example: If you have the system library, then you wouldn't need dependencies for building it from scratch.
        • Scott: There are already difficulty with licenses, and determining the set of licenses used.
          • Jacob: The set of licenses is conditional on everything picked up.
    • Resolution: It sounds like step-wise approach to mutually exclusive features (i.e. Ed's pre-RFC) is the path to get there.
Last changed by 
 
rust-cargo-team
Cargo team for the Rust Programming Language
0
119

Read more

Cargo team meeting notes

https://meet.jit.si/CargoTeamMeeting

Apr 10, 2025
Cargo team meeting notes 2025 Q1

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&apos;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. &quot;Here&apos;s URL, give me a file.&quot; A low-level system could help avoiding missing things in the future. weihang: Why can&apos;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

Apr 8, 2025
2025 All Hands Topics

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

Apr 2, 2025
Build Times: Cargo Perpsective

Notes to prepare for 2025H1 Project Goal planning

Mar 19, 2025
Read more from rust-cargo-team
Published on HackMD