owned this note   changed 2 years ago  
Published Linked with GitHub

Cargo team meeting notes

2023-09-12

Meeting canceled

2023-09-05

  • Project Director elections. If you have anyone you want to nominate, please let ehuss know.
  • home maintainership
    • Anyone with energy for ACP for a new homedir function in std?
      • Windows issue
      • What to call it?
        • std::env::home or something
      • Would fixing and undeprecating just work since it has been so long?
      • eric: Curious about some people don't want easy access to the home directory at all, but that is probably not a blocking concern.
      • Asking the maintainer to possibly help with this?
    • Consider a separate crate (less generic) like cargo-home.
      • And deprecating home, and pointing to the new standard library.
      • Ed: Can help with splitting that out, and working with rustup to use the new name.
    • Ed: Can help get the ACP started.
      • Josh: Can help from the libs-api perspective.
      • Eric: Can also help, but don't want to drive it
  • hi-rustin (and others?)
    • Wants to work on higher value items (ie team priorities)
    • More willing to get involved in decision making
    • Outwardly communicating priorities, might help with others.
    • Meeting times can be incompatible
      • "The time zone issue is really difficult, I'm fine with 8pm to 10pm UTC+8. Also I'm fine with 8am to 10am UTC+8."
      • Weihang (for now) and Jon
      • "three major timezones, pick two"
    • josh: Difficult to schedule meeting times across multiple teams.
      • Council feedback: Might help to coordinate the scheduling. Finding times that multiple teams could potentially work with. There are tools to help with this.
    • Scott: Cargo-contributor team could also be a value for scenarios like this.
      • Can provide another opportunity to meet.
    • Eric: About project planning and priorities.
  • Credential-process
    • Jacob: Just checking in on status.
    • Arlo: eric asked for some tests, can post a PR soon
    • Serialization of enums, tag is better compatible, default of untagged can be less resilient. cache-control could be one.
      • For example, adding data to an enum would break with untagged.
    • Setting msrv for credential:
      • Can set an independent msrv
      • Ed: Setting up a separate workspace for these external things.
      • Ed: The dependencies of cargo-credential need to be compatible.
      • Ed: created https://github.com/taiki-e/cargo-hack/issues/196 which might make MSRV testing easier
  • Could we discuss mirroring, and requirements/enablement from the Cargo side?
    • Josh: will follow up async.

2023-08-29

  • Cargo.lock announcement post
  • Disposition for Pre-RFC: pre-compiled macros
    • Process for current Pre-RFC has the appearance of being tainted and want to put a pause on the conversation for X months
    • There is already work on sandboxing of proc macros and we would encourage efforts to be put there in the mean time as it is effectively a blocker for the Pre-RFC anyways
    • eric: Wondering if we need to give a response? Generally we aren't required to respond to internals ideas.
    • Jacob: Technical points to bring up in the thread?
    • eric: Curious about breaking this into stages.
      • Ed: Would prefer to have sandboxing before end-to-end pre-compilation.
      • eric: Various stages:
        • WASM proc-macro in the compiler
        • rustup components for wasi interpreter
        • cargo configuration and support for wasm proc-macros
          • Offshoot: capabilities for sandboxing and build.rs support
        • cargo support for pre-compilation
        • crates.io support for pre-compilation
    • MCP is an experiment, would lead towards an RFC.
    • https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Build-time.20execution.20sandboxing.20compiler-team.23475/near/283702107
    • No indication we want to respond at this time.
  • Improve forking process
    • Easier patching with https://github.com/rust-lang/rfcs/pull/3177 for immediate mitigation
    • Easier patching with replacements
    • jacob: would like to see progress, but doesn't have capacity to be involved.
    • ed: also doesn't have capacity, but would like to see if we could put something like mentorship steps to move them forward.
    • ed: Background on [patch] not supporting different names?
      • Jacob: Social aspect, maintaining hard forks in the ecosystem is not good. Pressure to fix upstream, or to move everyone over, not to point in the middle.
      • eric: Technical reason: The way patch works is an overlay on top of the source. If that overlay gives a different response for something (giving a different package than what was expected), the rest of cargo could be confused.
        • Uncertainty around whether renaming would be able to support that. Version differences might be more difficult.
        • renaming happens earlier
        • we need the name and a compatible version to do lookups
      • Weihang: Is this something we want to accept now?
      • Weihang: [patch] won't apply in publishing.
        • An impediment but also a help towards our culture
  • Competing PRs?
  • Issue 12297: allow home to compile on wasm
    • Blocked on us deciding if the cargo team will be supporting this for general use.
    • Ed: Unfortunate that the name is general and doesn't indicate it is cargo/rustup-specific.
    • Weihang asked Lucio for feedback, but no response in 3 weeks. (Possibly has a new job.)
    • Weihang: Proposal to make it just not compile on wasm at all.
      • Or, to return None on all unsupported platforms.
      • No bandwidth to support it in the general case.
    • Eric: Would it be possible to fork this, and give the name home to an external maintainer?
    • dirs is commonly used, and provides access to the home directory.
    • https://github.com/rust-lang/rust/issues/71684
    • Arlo: Can we support wasm?
      • ed: The change itself isn't the issue, it's more about the intention of support for other people.
        • Would be ok to make the change, but doesn't want to keep kicking the can down the road.
    • eric: Notices BurntSushi is interested in un-deprecating std's home_dir (possibly with a different name with fixes), which could resolve the reason people want to use home in the first place.
    • ed: Should we be making a decision about support of home?
      • eric: Yes, we should probably decide on that or document it more clearly.
      • jacob: Is now the time, or the next PR? :D
    • Jacob: Compromise: Document it returns None on all other platforms? We don't want it to do anything else.
    • Eric: Ping Lucio. If no response, make it clear that we aren't maintaining home as a general-purpose crate (and maybe point to other options?).
    • Ed: Terrible idea: Rename [lib] to cargo_home.

2023-08-22

  • epage: serde_derive
    • Lessons learned?
    • How to handle Pre-RFC
      • Concern: process is tainted
      • Concern: we were already interested
      • Compromise:
        • Process for current Pre-RFC has the appearance of being tainted and want to put a pause on the conversation for X months
        • There is already work on sandboxing of proc macros and we would encourage efforts to be put there in the mean time as it is effectively a blocker for the Pre-RFC anyways
    • What technical improvements to help migrate off of serde?
      • patch too weak
      • Potential language improvements as well
      • Patch with a diff helps in the first couple of hours
      • Patch to crates-io helps for weeks
  • weihang: configuration merges lists in precedence order
    • https://github.com/rust-lang/cargo/pull/12515
    • This is a breaking change. How to calculate the blast radius?
    • concern: Some companies use layered configuration.
    • eric: How to raise awareness?
      • weihang: Maybe a blog post? Unsure?
      • arlo: Get into nightly so it can get tested.
      • Josh: Merge it and make a blog post to get feedback.
      • arlo: seems likely it will affect somebody.
    • eric: What are the scenarios that would cause problems?
      • arlo: example: if you had a flag in a more specific config, which is ignored, it will now be in effect which could break.
      • josh: try to detect the scenario that could cause breakage and provide a warning about the conflict
      • weihang: add a flag for the new behavior?
        • arlo: would prefer to not have a flag.
      • jacob: If there is a flag, it could help with testing where you could try both ways. But just an unstable flag (or environment variable) for testing that is not intended to be kept.
    • Josh: +1 for landing, announcing, getting feedback, considering further action iff unexpectedly larger blast radius.
    • Decision: Land now, inside-rust blog post (which should get in twir), make sure it is relnotes tagged, solicit feedback and respond.
      • arlo to write blog post.
  • epage: anyone want to be collaborating or review Cargo.lock blog post?
    • josh: can help review the finished version
    • arlo: Can you drop a link to help review?
    • "here's the change, here's the rationale, here's our recommendation"
    • considering how to solicit or respond to feedback?
  • epage: feedback and path forward on cargo new updating workspace.members
    • Does anyone want to work in a small group to move this forward?
    • eric: Is this fundamentally --workspace flag, or is it broader?
      • epage: Difference between "add to a workspace" and "create a workspace", and the default behavior.
    • arlo: Likes automatically adding to a workspace, as long as it doesn't screw up with wildcards.
    • arlo: --workspace might be a little confusing, it could mean two things "add to a workspace" versus "create a new workspace".
      • Naming is hard. :)
      • epage: --workspace takes an argument. false could mean don't add to a workspace, other values
    • arlo: Do we need an opt-out for the initial implementation?
      • epage: Probably not, we are already adding workspace inheritance automatically.
    • eric: Is there a preference for the CLI options?
      • ed: Adding a [workspace] should be an opt-in.
    • Is there any objection to have the implicit add without an opt-out?
      • eric: Just wondering if the blocker on the opt-out flag is just making a decision on the name/options of the flag, and if so can we make a decision on that? What kind of complexity is there?
      • No specific objections from anyone, eric will try to re-review and provide their own feedback.

2023-08-15

  • Arlo: Check in on registry authentication. Needing to try to justify the current approach.
    • Community feedback is pushing back on needing credential providers to support authentication in registries.
    • Uncertain about the path forward for stabilizing credential providers.
      • arlo: Thinking it looks good for the ~next month, but may not have gotten enough testing.
      • Waiting on some PRs for review.
      • Less confident on it supporting asymmetric hardware tokens.
      • Looking towards 1.74 stabilization?
    • Probably don't want to support 1password.
    • josh: wants to make sure libsecret works well, as well as Apple and Windows native support.
      • Should feel native support for each platform, even if it is separate.
    • Arlo: Seems comfortable with Windows or Mac
      • There was a concern about mac's dependency
      • Libsecret is a problem. Can't build in our build system.
        • Josh: Can it use dlopen to access libsecret instead?
          • That could allow us to have it built-in to cargo (even without libsecret installed). You'd still need to have it installed to actually use it. Wouldn't need the -dev packages installed.
        • This is probably a lower priority.
          • Josh: Agreed that supporting asymmetric is definitely a higher priority.
    • Arlo: Should the asymmetric -Z flag be separate from the credential provider?
      • Yes, probably.
    • Weihang: How many credential providers will we provide?
      • Concern over how much maintenance it imposes on the team.
      • Arlo: Other credential providers could be kept separate, not something we support directly ourselves.
      • josh: Can also invite platform experts to help with these, and review them.
    • Josh: What was the signing issue with macos?
      • It causes an extra prompt when using macos.
      • Signing would be best, but possibly something that would help in general. Could also help with restricting what has access to the secrets.
      • eric: Signing support has been a project for 5+ years, but it is very difficult since it requires a separate signing system.
    • Decision: Agreed to plan to stabilize in the next release 1.74.
      • arlo: Some help with open PRs is appreciated.
    • eric: Proposing adding support to publish from GitHub Actions.
      • Weihang: Concern about confusion with which crates are auto-published. Would prefer auto-publish with Rust releases.
      • Jacob: A file in the repo could list which versions are published, and then publishing could be triggered based on a normal PR that says to "publish this thing".
      • Jacob: Would like the crates to be independently versioned, so they can be published out of the Rust cycle.
      • Arlo: Make sure we're comfortable with one tag per crate.
        • git2 and ed's repos are doing this.
  • eric: Helping with rustup
    • weihang: I encouraged @rami3l to help there
    • If anyone can help, it would help since it is in a dangerous situation.
    • Scott: Why is rustup in a separate repo?
      • Ed: Can help with managing issues and PRs.
      • Josh: There are some items of value if they were more tightly integrated.
        • If there are points to reduce the effort to maintain rustup, those would be good to look at.
  • epage: feedback and path forward on test organization
    • Would anyone be interested in a sideband conversation on this?
    • Zulip thread didn't get responses.
    • Weihang: Move all tests to UI tests unless we cannot.
      • Ed: Would like some in-file blessings like some other tools. Some other things are needed to support in snapbox.
      • Ed: There are lots of tests that blur a line between how it is organized. Lots of historical evolution.
    • Jon: terrible idea, one test file per PR.
      • More to highlight the arbitrary nature of test organization
    • epage: A lot of test organiztion feels historical, that if written today we wouldn't do it that way
      • install_upgrade.rs is an example
      • eric: that is actually reflecting code organization
        • epage: When working with e2e tests, it seems like it should be focused on the user-facing side
    • eric: doesn't have as much uncertainty about where to put things, as usually organized based on code structure.
    • There are various examples of tests that have overlap between various areas, and can be hard to say which way it should go (PR affecting build.rs / rustflags)
    • Weihang: Suggestion on following something like the compiler team where tests are marked with issue number.
      • eric: Is against something like that. The compiler team is currently discussing an MCP to avoid their current organization.
        • github can't render the directory view…
      • epage: put in regular place with regular name but maybe add issue number to name
    • eric: Wondering if it would help to write down specific guidelines to help with how to place things.
      • Current guidelines:
        • UI tests go in command folder
        • Functional tests go in
          • -Zfoo, then foo.rs
          • `command.rs
          • Maybe feature.rs?
    • If people have more feedback, please bring it up on the Zulip thread.

2023-08-08

No Jacob

  • Josh: Check on status of cargo update
  • epage: Concern over crates-io validated manifests
    • See the PR for my concerns
    • Processes aren't in place for updating crates.io to support updates in cargo.
    • Updating debuginfo is an example.
    • Can we share some kind of parser with them?
    • Another option is to remove manifest validation.
      • Concerned about the amount of value versus the costs.
      • Partly up to crates.io to deal with people having problems, but could also come to the cargo team. Also a rust community problem.
    • Should be fine when new fields are added, mainly when old fields are changed.
    • Josh: would prefer if cargo and crates.io used the same parser. Using a third-party is puting work on us to do things.
      • Concerns over how responsive these third-party crates are to changes.
    • crates.io is interested in reading more fields from the manifest. Also reading the .crate file for targets.
      • cargo_toml has an abstract trait for reading from the compressed .crate file to discover if there are binaries and such.
    • eric: Asking about using a more general parser like toml::Value that is untyped so that any type changes wouldn't affect them?
    • josh: Can they use cargo to parse it?
      • ed: They would need to extract the .crate file to read the manifest.
      • Josh: They could read out just the Cargo.toml to a string, and pass that in.
      • read_manifest_from_str is currently private
        • May require reading from filesystem
      • Addressing this might be less work than trying to support third-party crates.
      • Josh: Can we ask them if using cargo would be ok?
      • Splitting it out to a separate crate would likely be difficult.
      • Using cargo would require a git or path dependency.
        • Josh: In theory we could publish nightly cargo versions, but that wouldn't be ideal.
    • ed: Question about supporting older nightly unstable features that have changed in a newer nightly.
      • Some projects pin nightly potentially for a long while.
      • Arlo: Likelihood is low for breakage.
    • eric: will follow up to see if we can investigate other solutions and to make our concerns clear.
  • weihang: stabilize --keep-going?
    • https://github.com/rust-lang/cargo/issues/10496
    • In nightly for more than a year since 1.61.
    • The recent comments show valid use cases.
    • One potential confusing element is --keep-going and cargo test --no-fail-fast.
    • Write up the scenarios for each thing.
      • Whether or not build jobs stop.
      • Whether or not cargo runs all test programs.
      • Whether or not libtest stops on the first test.
    • eric: Recommends changing --keep-going to also imply --no-fail-fast.
      • Would anyone want the behavior of "build as much as possible, but still fail on the first test program that fails"? Seems less likely, but it can be hard to predict what people might want.
    • --keep-going is a pretty wide-spread option, and -k is a common shorthand.
    • TODO: Review which tools have similar flags or behavior.
    • Weihang: Write a summary that clearly shows the behavior.
    • Eric: Will write a comment propose changing the test behavior.
    • FCP announcement could also spur time to respond.
  • epage: feedback and path forward on help proposal?
    • https://github.com/rust-lang/cargo/pull/11905/files
    • Should we iterate on this in a smaller group?
    • See https://github.com/rust-lang/cargo/pull/11905/files for what the output looks different.
    • Weihang: Will it get out of sync with cargo help reference?
      • All of the help is duplicated, and this would add some more.
    • Arlo: Looks better. Would like the markdown docs to have the same headers and order, and some tooling to enforce that.
    • Weihang: Be careful of help completion.
      • eric: Doesn't believe help is used in any of the completions.
    • Nobody had strong objections to moving forward. Will leave with Weihang and Ed in PR review to finish things out. If anyone thinks of any concerns, please bring them up in the PR.

2023-08-01

No Jon, Jacob

  • epage: thought seeding for later: How can we increase the rate of innovation?
    • What are barriers for contributors we can lower?
    • Discussed thoughts on doing more synchronous discussions among smaller groups.
    • How can we encourage more experimentation?
    • Maybe our contrib docs should explicitly encourage experimentation outside of the cargo repo?
      • Any guidance on feedback cycles and path for later integration?
      • "Working on large features" mentions working externally.
      • Questions about how to bring external things back into cargo. The shepharding process. Examples are things like nextest, which probably wouldn't bring in entirely.
  • epage: cargo new always inheriting
    • Compatibility of programmatic use of cargo new?
      • eric: can't specifically remember historical issues with programmatic cargo new.
        • Changing default from lib to bin was a semi-large change.
      • scott: Would prefer opt-out flags, and have automatic behavior for the common case. Advanced users can use the CLI to customize their behavior.
      • josh: Different defaults that may make sense for whether to be in the workspace by default, or to inherit by default. If already a member (like from a glob), adding the inheritence automatically makes sense. But if not, then can imagine going both ways.
      • ed: Would prefer to not have configuration. Consider the percentage of users that will be using the different options/use cases.
        • josh: Clarifying. Pick the thing that the majority will want, and then have some kind of "inherit" flag to specify what they want.
        • ed: Would be against having a flag for specifically controlling the inheritance.
      • Arlo: Can print a message with more detail about editing the file. Printing a warning that cargo automatically added it as a member.
      • weihang: Mentions cargo templates.
      • ed: More open to a flag of "add to a workspace".
      • Josh: If you default to inheriting, that is a reasonable default. If you want to opt-out of that, you're going to need to do 90% of the work anyways. Doesn't seem to onerous to do that.
      • Scott: Would be nice to have a lint that tells you that you can inherit your dependencies.
      • Josh: Question of which parts should be stable for programmatically.
        • After your run, you should have a crate with a reasonable structure. But the content is not necessarily stable.
        • We should never change the bin default.
        • Should never change that src/main.rs gets created for a bin, and src/lib.rs for --lib.
        • Expectations about what's in the manifest are not stable.
        • Ed: Uncertain if we necessarily want to make those guarantees, but also recognizes that it seems unlikely to change.
    • What should be the short-term solution?
      • eric: How difficult would it be to check if the new package would not be in the workspace?
        • ed: Not certain. Limits the usefuless of filling in the inheritence, particularly for people who don't use globs in the members.
        • eric:
          • Flag to add to the current workspace.
          • Flag to add to a different workspace.
      • Josh: If there is a glob in members, it makes sense to include the inheritence.
        • Wants to make sure whatever design doesn't make nested workspaces more difficult. "Which one?"
    • What should be the long-term solution?
    • eric: Proposal:
      • In the short term, don't add inheritence if it is not part of the workspace (so it isn't broken).
        • ed: Even without inheritance, it is broken.
        • eric: That's a good point, so I retract that suggestion, since it is already broken.
      • Eventually add some kind of flag to control how a package gets added to a workspace (with some default behavior to be determined).
        • eric: How difficult is this?
        • ed: Mostly figuring out the name of the flag (and perhaps TOML formatting).
        • weihang: If it updates the workspace Cargo.toml, does it need to have something like "ignore version control".
          • eric: Not particularly concerned, seems unlikely that it would particularly break it.
      • To address programmatic support: Something like cargo templates can provide a stable interface for that use case.
    • ed: Final decision: Close this specific programmatic issue, and pursue https://github.com/rust-lang/cargo/issues/6378 in the short term.
  • joshtriplett: Discussion on cargo fmt formatting Cargo.toml in style edition 2024?
    • Any objections to cargo fmt formatting it in 2024?
    • Please look at the suggested formatting.
    • Scott: Could be related to cargo lints, which could provide machine-fixable cargo fix.
    • To avoid formatting, there could be some kind of format-ignore setting.
    • Josh: Edition-migration mechanism could also migrate the manifest.
    • https://doc.rust-lang.org/nightly/style-guide/
    • Feedback on t-style (or t-cargo if that's what you want).
    • eric: Is there a standard style guide for TOML in general?
      • Not particularly.
  • epage: any feedback on cargo upgrade before FCP?
  • (epage: feel free to insert items before this)
  • epage: path forward for lints RFC
    • Josh volunteered :)
    • Anyone interested in smaller group discussion for hashing out
      • Workspace-wide lints within cargo
      • doctest details
      • Whether to handle crate-specific lints and how (e.g. lib vs test)

2023-07-25

No Jon

  • ehuss: Inform: Point release completion fix.
  • weihang: Working on automation for handling bumping versions in cargo's workspace.
    • Arlo: question on how cargo's crates get published.
      • Published at the same time the Rust release goes out, off the stable.
      • credential: Currently published manually.
    • ed: Likes to publish on each PR, doesn't need to think about what is in each release, fast access to people who want that change.
  • epage: Working on something that can test completion scripts.
  • epage: CAD97 reached out, willing to transfer build-rs ownership to cargo and help maintain in order to have a good name for a blessed build script API crate
    • So far cargo hasn't provided crates that provide APIs for correctly interfacing with cargo.
    • Jacob: Having a library that encodes the best practices for handling build script things like vendoring of libraries, etc.
    • weihang: Should libraries like build-rs be available via rustup.
      • ed/josh: That would make it hard to version the crate so that it can change API, due to needing to ship new versions.
    • Josh: Good for parsing multi-value env vars.
    • Arlo: Makes the cargo:: change less invasive.
      • Josh: Though it needs adoption from the community. But if we have build-rs available, then the :: change is a good opportunity to say "as long as you're migrating, migrate to this crate instead"
    • Jacob: build-rs could do version checking if the new syntax wasn't available.
      • Ed: Or a new version with the MSRV set.
    • Ed: Taking on APIs, what should the MSRV be (and associated release process)?
    • josh: supporting new features in build-rs. build-rs could detect some kind of feature advertisement to know if it is supported.
      • Ed: Or, have a cargo "unstable" feature flag.
    • eric: Question about the API, do we want this as-is, or does it need changes?
      • ed: Would like the lower-level aspects in a "raw" submodule. Another crate had something like a Context struct, and that would handle state like rerun-if-change. Good for helping people doing things correctly.
      • Ed: Would also like a crate with macros for all the env vars.
        • Uncertain about what to name that (would like namespaces to skip that question).
    • Naming: build-rs crate name is build. Uncertainty about naming in general.
    • josh: Other best practices: 2 or 3 different ways to "fail with this message". Printing, versus, panic, or exit(), etc.
    • eric: Question if ed or someone wants to drive this forward?
      • jacob: A proposal, a shared understanding of what we want to do with it.
      • ed: create a couple of issues of apis we think we should have.
      • Josh: do a cursory review that we might want to remove before we declare this as the newly adopted version. For example, compatibility with ancient cargo, or things we don't think people should be using.
      • Weihang: How will permissions work for allowing CAD (or others) to maintain it?
        • Josh: Probably want to keep permissions on cargo team.
        • Weihang: We can ping them to review.
      • Jacob: Proposal could discussion issues like CI or publishing.
    • eric: Just random observation about considering how breaking changes are done (for example, the change to cfg families that changed to multi-value).
    • ed: Will move forward with issues.
  • arlo: registry-auth stabilization
    • require a credential provider to be configured (even if that provider is cargo:token?)
      Sample error when a credential provider is not configured: 
      ​​​​The registry '{}' requires a authentication, so a Cargo credential-provider must be configured.

​​​​See https://doc.rust-lang.org/cargo/reference/credential-providers.html for details.
    • stabilize as-is? Available without requiring a credential provider.
    • Arlo: This has gotten the most questions when it will be available.
    • Jacob: More comfortable with it, though uncertain if they are quite there.
    • Arlo: Should cargo:token be disallowed as a credential provider. Someone could just as easily make a provider that does the same thing.
      • Jacob: That ends up being a meaningless speed bump if that's what someone wants.
    • Arlo: Still interested in having the error message just so people know what credential providers. This helps encourage people to look into them, to avoid storing plain-text tokens on the filesystem.
    • Jacob: The higher the speed bump, the easier to say that is the deprecation path. If we never deprecate, it is a moot point. Could go either way.
  • asymmetric token stabilization
    • currently enabled via -Zcredential-process and cargo:paseto
    • Arlo: Now available as a built-in credental provider, changed to -Zcredential-process.
    • eric: Where are we at?
      • Arlo: Would like to see a registry support it, at least to get more testing. Probably not sufficient testing.
      • Scott: What changes have been made?
        • eric: The workflow changed, cargo login no longer has flags for setting it up.
        • Arlo: secret-key-subject may need manual editing of a config file.
        • Jacob: Uncertain about if the crates.io team would allow unstable auth things, or what their interest in.
      • Arlo: Should the paseto provider be under a separate unstable flag?
        • Eric: Suggest figuring it out when the time comes?
      • Arlo can ask crates.io to see how they would feel about experimenting with it, but we don't have much bandwidth to actually work on it in at least the next month.
        • Since they recently were working on auth, it may be fresh in their mind.
      • Eric: Also wondering about github oidc support in the future.
  • credential-provider stabilization :
    • cargo:token - currently the only stable option
    • cargo:macos-keychain
    • cargo:wincred
    • cargo:1password - should possibly be moved to external crate
    • cargo:paseto - stabilizes asymmetric tokens
    • cargo:basic [..] - stabilizes the basic protocol
    • [external-provider] - stabilizes the JSON protocol
    • Eric: Concerns about stabilizing most of these.
      • Uncertain if anyone will use them. Uncertain about the maintenance burden.
    • Jacob: What is basic provider? Be careful about how this is documented. This could be confusing with other auth systems which also use the name "basic" (like HTTP auth).
      • Arlo: Could rename it, like adaptor (or adapter)? LOL.
    • Jacob: Could stabilize only cargo:token as a meaningless piece of boilerplate for a version or two.
      • Arlo: Would also like macos-keychain and wincred.
        • A little hesitant to stabilize the JSON protocol right away.
      • Question about why PASETO?
        • jacob: Had access to a security expert who recommended that format (who also wrote it), and followup conversations indicated it was a reasonable choice, among other choices.
        • "pah-set-oh"
    • Would like to move forward with the plan of stabilizing credential-process as a means to support third-party registry auth. Will double check with Josh (unavailable in second half of this meeting).
      • Not entirely certain on the exact parts that will be stabilized, but will likely at least be token/macos-keychain/wincred. Uncertainty particularly around basic, will need to follow up on that. Still have some time since the major rewrite isn't even in nightly, yet.

2023-07-18

  • Issue 8728: Check-in Cargo.lock
    • Table of content
    • Ready to move forward?
    • Jacob: Regarding the blog post about minimal versions. Part of the goal is to spread out the effort, so you aren't asking people to do too much, and not all work done by one person. How much work you ask the community to do can change because it has gotten bigger.
      • Wondering if the size of the community changes the calculus about how the testing is being spread across more users.
    • Arlo: no strong opinion about it. People can do it already, this is just about the default. For deterministic builds, checking it in is desirable for that.
      • Regarding CI time concern, people can still choose to only test one or the other (latest or locked) if they don't want to do the extra test.
        • Ed: The guidance includes the tradeoffs to let people know.
    • Weihang: From company's perspective, their build system does some tricks around Cargo.lock. Will provide more feedback later.
    • Jacob: The best practices documented at $job may not match Cargo's documentation.
      • Ed: Curious where policies don't align, and where they can meet in the middle.
        • Similar: Rust-for-linux reaching out to testing team to bring someone out to have conversations about their needs.
        • Interested in representative cases and perspectives that can highlight situations that others might share with it.
    • Scott: Reservations about not always having testing latest versions. It is a necessary thing for consistency. Bisecting code can be troublesome without the lock, though.
    • Ed: Recognizes that there are tradeoffs.
    • Scott: This could potentially be a reversible change.
      • Ed: Also interested in the 6-12 week time span to gather feedback.
    • Josh: Given how widespread the advice has been (and mixed), there isn't one answer that solves every problem. Some are unambiguously worse than others. The current approach of being inconsistent between crate types is suboptimal. Since this advice has been pervasive, they may not look it up. It'll be passed via word-of-mouth. A blog post would be good (and possibly on Twitter) sounds like a helpful step. It can let people know we know there are tradeoffs, and let people better understand.
      • A full blog post would not be unwarranted.
      • Ed: Asking about the inconsistency of the current policy.
        • Josh: Acknowledges the tradeoffs, but the inconsistency is worse in a sense that it doesn't make those tradeoffs differently. Doing it consistently either way is better. At the end of the day, with MSRV resolving, that will eliminate the reasons people are having trouble. Having more information is better than having less.
      • Ed: The importance of the advice that the advice is agnostic of the kinds of crate types.
    • Jacob: Sees having different strategies of testing things in the ecosystem could spread those different ways of testing.
      • The methods of the community are mostly "use latest". If there is a problem with an older version, the answer is normally "use latest". Not much accomodation in the community for using older versions.
      • Ed: The ecosystem has changed a lot since the early days of cargo. CI is much easier to use. Dependabot didn't exist. etc. Still considering ways to avoid stagnation.
    • eric: Question about how to communicate this with the community.
      • Ed: When people have opinions, it matters whether they feel like they had a voice. TWiR doesn't follow Cargo FCPs, and doesn't give people a comment on non-RFCs. The blog post will give people an opportunity to share their opinions and have a voice, pointing towards the issue.
      • Josh: Wondering if we can change TWiR to handle Cargo FCPs, sounds like a win.
      • Josh: The blog post at the beginning of a nightly cycle would maximize the time for people to give feedback. Phrase the text of the blog post, this is our current plan, if you want to come talk, here's where to talk (an internals thread, a cargo issue, zulip, etc.). The change itself is trivial. The complexity is in the rational and documentation and education.
        • Jacob: Also echos how the announcement is made makes a big difference to how it is received.
      • Ed: Nothing pressing for it to be done right now, more of a vague feeling of concern over people using upper bound version requirements due to the lack of lock files.
      • Jacob: Communicate the change from pithy soundbite to a clear outline of the pros and cons (or tradeoffs).
        • Ed: "When in doubt, check it in", and then there is more information about making that decision.
      • Jacob: Not recommending to immediately change your CI setup, but if you are unhappy with what you have, here is a more in-depth look at our thought process.
        • Ed: Don't rush to change. If it works, it works.
    • Arlo: Does there need to be some mechanism for unlocked testing beyond running cargo update?
      • Ed: One concern with cargo update was read-only testing. People using read-only testing (like containers) likely already have bins or Cargo.lock.
        • Jacob: or cargo generate-lockfile
    • Jacob: Waiting for FCP before PR follows the process.
    • Arlo: Will ask about getting cargo's FCPs in TWiR (and this particular issue).
      • Ed: Link to the 8728 issue. Doesn't have an opinion on the issue versus internals for feedback.
  • JSON format regression in 1.71
    • https://github.com/oli-obk/cargo_metadata/issues/240
    • "debuginfo":"line-tables-only" changed type from integer to integer|string in artifact messages.
    • Goal: Discuss options for addressing this.
      • Ed: Only impacts people using the new debug option.
      • Josh: Breakage when optining in to
        • People are expected by some means to parse the whole JSON. They are parsing the whole thing, even if there aren't things that they aren't using. Arguably this is a bug in whatever code is parsing this. Should the expectations for parsers to ignore things they don't understand?
        • Scott: With workspace inheritence, reached out to see what kind of impact it might have.
      • Arlo: Adding new fields should be fine, but changing the type less so.
      • Weihang: If cargo maintained cargo_metadata crate.
        • Eric: If we just maintained it as-is, that wouldn't have changed things. If the deserialized types were shared between cargo and cargo_metadata, then we would have seen an API break. That still requires the reviewer to make the connection that API break=breaking cargo's compatibility.
        • Weihang: Oli is happy to let the cargo team co-maintain or take over.
      • Arlo: Can cargo-semver-checks check this?
        • Eric: Yes. But it requires someone still equating "semver breakage" to "this will break other users".
    • Goal: Discuss options for managing future updates that may affect the schema. (If we had known ahead of time, what would we have done differently?)
      • Jacob: This is awkward because we are caught in the middle. The type-based change was in rustc, and this didn't carry the conversation to cargo or others about the consequences of that.
      • Eric: I saw every step (the MCP, the rust change, the cargo PR, etc.), and I never made the connection that this would change Cargo's JSON format.
      • Ed: This isn't strictly a type change, expands the types supported which makes it harder to
      • Weihang: Change our compatibility guarantee around these issues.
        • Go has https://go.dev/doc/go1compat which documents the guarantees. What about having something like that ourselves. We can expand that list over time.
      • Ed: Another example of breakage was when optional dependencies changed in cargo metadata.
      • Josh: Talk about version number that could pass into cargo.
    • eric: Will follow up with changes to cargo_metadata. Should also continue the conversation at some point about the compatibility.
  • Windows networking issue

2023-07-11

  • Check-ins
  • epage: Milestone check-in on "cargo script"
    • Less-invasive changes are in
    • Check-in on experiment before committing to more invasive changes (e.g. workspace support)
      • Example invasive change to support workspaces is to change SourceId and other things.
    • josh: Question about separating workspace support and similar from the current state, to reduce cargo changes required
      • Some things like workspace support were highlighted in the RFC as things that could be done later.
      • ed: controversial point is default of the edition field, wanting to default to latest.
        • warning if you do not override the edition (it tells you what the current default is). That allows short-term scripts to not bother with the boilerplate to quickly write them, whereas people who want to reuse a script, the warning will drive the user to do what they need to do to squelch the warning and have a more stable script.
        • In a workspace, workspace inheritence could provide a way to have defaults for edition.
        • Nuance to supporting workspace now versus later.
      • josh: cargo publish/cargo package not as important for scripts; similar importance level to workspaces
      • ed: different camps, prototyping, automation, xtask-like behavior. Some use-cases want workspace support, for example.
        • Josh: another example use case is test cases.
        • Separating out the importance of different use cases when considering the invasive changes.
          • Staggering out the changes, so that people can get access to some of the basic support earlier, and then supporting other use cases that require more invasive work later.
          • ed: While the experiment is going on for a long while, might as well work on some of the things that would otherwise be deferred.
      • ed: Another use case mentioned was for using as [lib], not just a bin. Essentially a single-file package you can use as a dependency.
        • A text-based general-purpose single-file container format can contain lots of things. Not in favor of following that.
      • ed: Doesn't want to cover all use cases. Likes idea of having explicit non-goals.
      • josh: thing about supporting build.rs, then perhaps you just need a full package in that case (although it would be nice to reduce the situations where build.rs is needed in the first place).
      • josh: in contrast to build.rs, supporting some form of embedded Cargo.lock is desired to support reproducible dependencies (similar to the motivation for cargo install --locked)
        • ed: workspace support can possibly help with the locking issue.
      • arlo: question, is the importantance being a single file (self-contained) or is it to support a shebang (with possibly multiple files)?
        • ed: for some of the use cases, additonal files dirtying up the directory is undesierable
        • ed: <script>.lock can be a little ambiguous, because how would cargo know if it should drop a <script>.lock file separately in the same directory, or embedded in the file. And today the manifest can't explicitly specify the location of Cargo.lock.
        • ed: see also https://github.com/epage/cargo-script-mvs/blob/main/0000-cargo-script.md#lockfile
      • arlo: question: how does the dependency story work with Python with single-scripts?
        • Python has various different systems for managing dependencies, but in general the answer is "no", there isn't a single-file script solution.
        • The standard library covers many different cases, though some modules have third-party alternatives that people usually recommend.
        • https://dbohdan.com/scripts-with-dependencies lists some examples in different languages.
      • josh: Some way to record the lock format to have a smaller format that can be embedded.
        • ed: A previous request was to have a way to "resolve at this point in history".
        • josh: Is there appetite for having a compressed lockfile format for scripts?
        • https://github.com/epage/cargo-script-mvs/blob/main/0000-cargo-script.md#lockfile contains some different explorations of how to handle the lock file.
        • ed: hasn't thought too much about the brevity issue, mostly focusing on the workspace angle. If placed at the top of the file, that would be bad, but at the bottom may not be as much of a problem.
        • josh: a single dependency can explode to a huge number of entries in a lock file. Scripts may commonly use frameworks or other things with many recursive dependencies.
          • Small changes can give a lot of value in terms of compressing it losslessly.
    • TWiR Call for Testing went out and seemed to go well
    • Major design questions remaining
      • Manifest format
      • Lockfile support (or can it be added later without being a breaking change)
      • Handling of editions
        • ed: Recommends trying the current implementation to see what you think.
      • Lib-support? Multi-crate or multi-package support?
        • We previously shot down build.rs and multi-package but some talk about it on t-lang for reproducing more complex cases
      • eric: get more testing, experience reports
      • eric: Windows support and filename extensions.
        • ed: an extension could help with double-click behavior, but that doesn't help with actually running it on the command-line.
          • What is the expected behavior on the Windows side?
          • Could potentially associate with regular .rs to invoke something as a script.
        • PathExt can provide a way to list filename extensions that are executable.
        • Shebang in a Cargo.toml file.
        • Generally Windows doesn't make this kind of use-case work very well. It is quite common to manually type python3 foo.py to run an interpreted script.
        • josh: A workaround is to use cargo install script.rs and then it would be in their PATH to execute directly.
        • Another workaround is to have stubs (like .cmd) that call cargo.
        • ed: how does rust-analyzer know to treat a file as a standalone script? A different extension would help, but another alternative is to check for the shebang.
        • ed: Good to document those workarounds.
        • No major concerns about Windows at this time.

2023-07-04

Cancelled

2023-06-27

  • checking on status of cargo#11188.
    • Eric to double check notes on what else besides the current concern is pending, ping author, look at cancelling the fcp if needed.
  • Check on Sigstore discussion
    • Jacob: They may be coming back with an update to the RFC.
  • Editions as integers (nominated)
    • Edition is an identifier but speaking / writing it for people looks like a number and requiring quotes makes it harder to make sure people write it out correctly
      • But by being a number, hex, octal, and binary formats are allowed which is weird
    • Why is resolver a string as well? Does that inform on this discussion?
      • eric: it offers more flexibility, and is more consistent with the rest of the manifest.
    • Would require bumping MSRV
      • Would be fine for new editions (since they already imply a newer MSRV)
    • Reviewing comments from the past at https://github.com/rust-lang/cargo/pull/12301#issuecomment-1602646000
    • jacob: papercut, only gets harder over time to change. But there are transition costs.
    • Josh: msrv: cargo new unquoted in 2024, leave it quoted in 2021 to avoid any MSRV implication.
    • weihang: Does it just save two characters?
      • ed: it also helps with human communication (verbally)
    • Josh: consider other integer-like fields separately.
    • eric: slight concerns about the transition costs.
    • ed: asking about Cargo.toml styles in the style team.
    • Arlo: what is the original motivation
      • ed: Mostly coming up due to cargo-script discussions. Communicating how to enter the edition in the script could be confusing.
      • josh: easier to mentally parse
        • "This looks like a number, why do I have to write it as a string?"
        • Also the verbal communication of explaining what to type.
        • Visual simplicity.
      • weihang: fix via cargo fix, it shouldn't need to be typed?
    • Options:
      • support strings
      • Better error messages
      • Support integers, warn, and cargo fix can fix the warning.
        • josh: not sure about issuing a warning, would prefer to not have a warning
        • arlo: also would prefer to not have a warning
    • josh: the documentation can explain that two things are supported, this is the standard syntax.
    • weihang: people only check the stable documentation, but may be stuck in an older cargo, and then be confused when numeric integers don't work.
    • scott: If rustfmt handles it in the future, it can transition it.
      • josh: would prefer for it to be cargo fmt and not rustfmt.
    • Josh: separate out decision of supporting cargo fmt
      • Jacob: Would think it is the opposite, that cargo fmt would be needed for it.
      • Scott: Generate an error. Have cargo fmt fix it to be a string?
      • Arlo: no precedence for fixing errors
    • Josh: Parsing vs canonicalization and formatting
      • Ed: The underlying decision is if it is worth it.
    • Scott: Are there any other fields that allow an integer other than profile.*.debug?
      • Was recently changed to a string. Integers aren't allowed as a string.
      • There are some things that support multiple datatypes, like publish which can be bool or array.
      • opt-level (number or "s" or "z")
    • Will continue discussion asynchronously (Zulip). Josh is still very interested in it.
  • Embed config-relative paths as a substring (nominated)
    • Ability to have paths relative to a config file (instead of the workspace?).
    • ​​​​​​[env]
​​​​​​CFLAGS = ["-I", { value = "include", relative = true }]
    • weihang: Other solution ideas?
    • Normally the [env] table is a mapping to strings. This is suggesting adding arrays with inline tables.
    • Josh: separate out, do we want to support this vs the syntax.
    • eric: What is it relative to?
      • We don't seem to know?
    • Josh:
    • eric: Asking for more information, what is it relative to? What situations is it needed (build scripts, etc.)?
    • jacob: relative = "…" (a string) to determine what it is relative to?
  • RFC 3371: CARGO_TARGET_BASE_DIR
    • Josh: Understands the use case, but is wondering about shared cargo dependencies, if we added that mechanism (+gc), do we still want this? Is this the feature people actually want, or is there a better feature that would subsume this?
      • ed: orthogonal to per-user cache. That has a focus on immutable dependencies, whereas that would still leave a local target directory.
      • Josh: asking about how it moves the target directory, you now need to find where that is in order to run or copy things.
        • ed: opt-in, symlink can provide a mechanism to find it
      • backup, easy cleanup, security software required authorization (but things like /tmp weren't restricted).
      • Put target directories on a ramdisk
      • Josh: Would a variant be to move everything into a shared location (internal stuff) except for the things people actually want (like the binaries)?
        • Discussion about finding the location:
          • Possibly a cargo subcommand or flag to cargo metadata to get that. Symlink target dir? Some other options in the RFC.

2023-06-20

  • eric: dependency guidelines for the contributing guide
    • eric: would that be useful?
      • jacob: could be useful to have it written down
      • josh: writing down rules of thumb we use internally would be a good idea
    • eric: thoughts of things they would like to have?
      • tidy license check
        • weihang: would be nice to have that checked in cargo's CI. Would it be possible to use the same checks?
        • josh: currently have exceptions for the OpenSSL license (and things derived from it), but would prefer to avoid introducing any new GPL-incompatible licenses.
    • eric will follow up with a PR for further discussion, please send feedback if you have any ideas.
  • epage: Tomasz Nowak's masters project
    • Worked on cargo-semver-check for bachelors
    • From October 2023 to May 2025, working 15 hours/week. Can be a little short but can't be too short or easy. If it runs too long, will write up on what was learned
    • Can range between practical and theoretical
    • Prior experience with compilers, algorithms, and optimizations
    • Should be trying something new instead of improving an existing product (e.g. revive and stabilize parallel rustc" would fit requirements)
    • Expressed interest in per-user cache of deterministic builds
      • Maybe also include last-used tracking to make it extend out
      • Maybe extend it further with remote cache research?
    • epage can mentor. Any others interested?
  • epage: Reducing build output for cargo script and generally?
    • One idea:
      • When tty, progress bars that disappear when build is complete?
      • build could still produce a summary but not run
    • josh: having an indicator for cargo script, separate from that to have it be prettier.
      • If a tty, use the current progress output. If not, disable the output (like quiet mode).
      • epage: wants to get rid of the verbosity even on a terminal.
    • epage: possibly clearing the output when it's done.
      • josh: more complex based on terminal capabilities
      • epage: solution similar to buck/bazel
      • josh: adversarial environment, the user of buck may be on a more modern terminal, cargo seems likely to end up run on less capable terminals (e.g. IDE or CI environment trying to fake a TTY so it gets pretty color output)
      • jacob: suggest a Rust-based terminal library that is well supported that we could use.
    • josh: the important line is the progress bar showing "Building" and the list of currently building crates.
      • arlo: and "blocking"
        • josh: Agreed; we could make that a one-liner that disappears when no longer blocking
    • eric: asking for a sketch of what a more general solution might look like
      • epage: having a trait that could generalize the reporting, and sending messages to it to be rendered with more context.
      • There are things like the build process which sends messages between threads.
  • weihang: stabilize -Zconfig-include
    • https://github.com/rust-lang/cargo/issues/7723
    • error/warn/ignore when file missing?
      • josh: if this is a proposal to stabilize, we don't want to add/change things immediately before stabilizing.
        • stabilize the feature as-is, and add features later in the future. Make sure space is carved out for that (e.g. make sure include = { ... } can work in the future).
      • epage: don't want to block on holding back for that
    • add more features or stabilize as-is?
    • eric: what is the main motivation for stabilizing, what is the use cases?
      • weihang: Generally useful, but since it is not stable, it is not really usable.
    • josh: question about relative path
      • Path is relative to the config file that included it.
      • What about environment variable?
        • Not currently supported.
    • command-line option is already stabilized.
      • --config $PATH
    • This wasn't stabilized before because the utility of this feature was unknown.
    • There was an unresolved issue about restricting the names to avoid collisions with future additions.
      • weihang: consider restricting names to ascii?
      • josh: unlikely to be a major problem.
      • arlo: agreement with enforcing the .toml extension
      • eric: concern about possible name collisions. For example, a user creates a file called ".cargo/cache", and then in the future cargo wants to create a directory called .cargo/cache/, that would collide with what the user specified. Restricting to .toml extensions would avoid that since we won't make a directory named with a .toml extension.
      • Escaping for something like *?
      • josh: Recommend .toml restriction, but otherwise just treat it as a path.
        • Can later extend with an inline table, with options to extend.
      • weihang to add a .toml check.
    • Loading priority of array of paths.
      • It loads includes as a special-case, so they don't work the same as normal config values. They work in a recursive manner.
    • weihang: will take on fixing the documentation so that it includes things like the array syntax, the precedence behavior, etc.

2023-06-13

  • No Scott for a few weeks
  • Registry auth (needs Josh, Arlo)
    • Is there a compromise that can encourage doing something more secure, while supporting auth techniques registries are more familiar with?
    • Background:
    • Previous discussion about JWTs: https://internals.rust-lang.org/t/pre-rfc-jwts-for-private-cargo-registry-authentication/18701
      • Reaction was not positive, why JWTs, not secure, can easily work around, don't like JWTs
      • People aren't satisified with the answers.
      • JWT is mostly driven by GitHub OIDC
      • If you are sufficiently motivated, you can stuff an opaque/bearer token in the payload to circumvent the security.
      • Ed: "We're protecting against Murphy, not Machiavelli."
    • If proposing another compromise, try to stick to it.
      • Unlikely to get a full consensus, there's always going to be tradeoffs that some people may be unhappy with.
    • Which option seems more maintainable, likely to lead to better outcomes. There's no one true answer here, we just have to make a call.
    • arlo: Pushing on credential-process as a compromise that will assist.
      • This is complementary to asymmetric tokens
      • jacob: concern about the ease that insecure proofs of concepts would be used
    • jon: requiring a credential provider for a symmetric token
    • josh: supporting GitHub OIDC should take at most one line of configuration, it should be trivial to enable for GitHub Actions. And it shouldn't require any cargo install.
      • Make sure that the UX is good (proper caching behavior, ease of use, etc.)
    • jacob: cargo login with a registry should only allow asymmetric or a credential provider.
      • Proposal: current stable behavior is kept for crates.io
        • Private registry, either credential-process or a credential provider.
        • In a year, we can decide to revisit this decision to offer something more permissible (which is a one-way decision).
      • Arlo: concern, some want this stabilized soon, but credential process may take longer to get stabilized (or asymmetric tokens).
        • May have a built-in provider that can read environment variables.
    • josh: Is it possible to ask GitHub about asymmetric tokens for OIDC?
      • Python's registry and other services exchange the GitHub Actions token for a registry-specific token.
      • Concern about the efficiencies of doing an exchange.
        • cargo -> GitHub OIDC -> crates.io -> cargo -> publish
        • one versus two requests doesn't seem that significant
      • Future formats (such as moving beyond JWT). This shouldn't be an issue since the credential-process will be responsible for creating whatever format is needed.
      • josh: I was confused, thought that credential providers would still be restricted to JWT; didn't realize the proposal was that credential providers could use any mechanism they want.
    • eric: question about the user experience for an arbitrary registry user.
      • arlo: Using credential-process would require using one of the providers.
      • jacob: a credential-process could just echo the token
        • arlo: we should probably not recommend that
        • Just acknowledging that is potentially something someone could do; we're not recommending it, but we can't stop it.
      • eric: concern that the UX for (current) credential-process is not very good, particularly on Linux.
        • jon: this would be an incentive to make it better
        • jacob: Can evaluate in some time whether or not credential-process is sufficient
      • UX with asymmetric tokens is pretty good, it is just something in a config file.
      • The credential-process protocol shouldn't be a problem if we later resolve signing issues or whatever.
      • Getting asymmetric tokens implemented on crates.io would help a lot with getting some experience with it.
      • Can possibly have a separate rustup component that contains the credential-processes, possibly as a way to get around the build problems?
      • eric: Doesn't really know much about libsecret, if people actually use it, what platforms it works on, etc.
      • Currently the gnome version can be installed via cargo install.
      • eric: The alternative is to just support bearer tokens in credentials.toml.
        • ed: Since cargo doesn't use XDG, the credentials could potentially be backed up in an insecure way. Ex, people putting dotfiles in GitHub.
    • eric: How long to stabilize credential-process and asymmetric tokens.
      • Arlo working on updates, will likely have a PR soon, would like to get it stabilized soon.
      • Jacob: Limited on someone doing the work, jacob burned out and probably won't be able to work on it. Probably not a lot left to do.
        • Weihang can possibly help.

2023-06-06

  • arlo: working on credential-process updates.
    • feedback during office hours
    • extensions:
      • telling the credential provider what the token is needed for
        • asymmetric tokens
        • indication of caching
      • Add support for fallback helpers
    • concerns on adding complexity
      • weihang: are there remote credential providers?
        • arlo: the provider process can handle the remote requests as it needs
    • jacob: asymmetric support moved into a separate crate with its own protocol?
    • arlo: credential providers can be built-in, or separate processes.
    • more flexible solution is an external thing that handles the fetching itself.
    • eric: login takes over the prompting?
      • Yes. In some situations like asymmetric, it's not clear for what cargo would prompt for.
      • eric: how would you pass the token in automatically?
        • use a pipe
        • if there is a tty prompt, that makes it harder
        • if stdin is not a tty, cargo could read the input and relay the input to the credential provider
      • jacob: anything piped in could be passed along to the credental-provider
      • eric: concern over the stdin reading from the credential process. The current 1-password approach seems to work, but I'm uncertain on how reliable it is.
        • It does fail with piping.
    • jacob: standardization of http auth like AWS Sigv4
      • What will be the impacts of these future changes?
    • Should the authentication header information be passed to the credential-helper?
  • eric: Last-use tracking proposal
    • Possibly gating for cargo-script, (and previously build-std)
    • Tools that modify private structures like the database. What are we willing to make easy/available?
    • Because cargo may not provide all the arguments that people may want, they may write their own tooling which reads from the db.
      • Various minor edge use-cases (crater, docs.rs, etc.) that might have unusual needs.
    • Some method for clearing stale entries in the database.
  • eric: question about how to communicate the status of an RFC
    • ideas: labels, project board, comment (like a triage comment), update top-level description
    • rustbot commands ready/author?
      • have r? comment link to the documentation
  • jacob: checking on sigstore rfc response
    • No response yet, eric to double check with outside communication
  • (low priority) Outstanding RFCs: https://github.com/rust-lang/rfcs/pulls?q=is%3Apr+is%3Aopen+label%3AT-cargo

2023-05-30

  • cargo-semver-checks:
    • Concerns
      • Trustfall, about bus factor, ongoing maintenance
        • eric: my sentiment is that it should be fine for now. In the worst case if Predrag becomes unavailable is that we can either take over maintainance, or fork it, or switch to something else. Those are unfortunate drawbacks, but probably better than doing nothing.
      • JSON not stabilizing soon
        • JSON not having enough information, example does it contain enough information about macros? Are these fundamental limitations to this approach?
      • Can cargo-semver-checks handle things like Cargo.toml, etc.
      • People might get a false sense of trust if it doesn't have enough coverage.
      • Predrag wanted public/private dependencies, other things (see issue)
    • Analysis was done of top 1000 crates dating back to 2017 to figure out how frequent breaks are.
    • public/pivate dependencies listed as a blocker, but that might not make progress in the foreseeable future.
  • weihanglo: build.jobs=? bikeshedding
    • finding a clear term is a little challenging
    • arlo: "default", do what cargo thinks is best
    • 0 has some precedence with buck2 and meson. Ninja has a different meaning.
    • 0 is fairly natural with the negative numbers.
    • jacob: CSS "unset"
      • "none"
  • eric working on last-use tracking proposal.
  • (low priority) Outstanding RFCs: https://github.com/rust-lang/rfcs/pulls?q=is%3Apr+is%3Aopen+label%3AT-cargo
    • Safe file discovery: https://github.com/rust-lang/rfcs/pull/3279
      • eric to propose to merge soon
      • future-incompatible warning?
        • Driven by rustup, difficult to get releases
        • hypothetical, we merge now, it could be 6 months before released and then another gap before switching to error
        • Why? release process is broken? Lots of steps and hand offs. Lots of sync steps. Docker image issues in past
    • Feature metadata: https://github.com/rust-lang/rfcs/pull/3416
      • Some information might need to go into the index, which would need a new schema version
        • example, private features shouldn't be activatable in a dependency (only within same manifest, or command-line)
          • that might be able to be stripped on publish
          • better error messages?
      • unstable: only other unstable features, or the command-line
      • eric: wondering about splitting this rfc up, or why these are all combined together.
        • These are somewhat related to one another, can be disruptive for things like reving the index.
      • Would doc be opaque or markdown, etc.
      • Error messages around v being updated is not good.
        • config.json could contain information about when different v values were stabilized.
        • Display a link. Cargo could say "I can't support this, go see here for more information".
      • ed working on updating the query API to include the things that get filtered (yanked, v mismatch, etc.).
        • jacob: also include "unparseable"?
      • Concern over size of the index, things like "doc" probably shouldn't go in.
      • evolving the index format, for example "features3".
      • eric: regarding splitting this RFC, if there are specific fields they are more interested in, splitting those out might get merged much faster. Particularly if there are fields that don't involve changing the index, those changes might be substantially easier.
      • eric: When considering a v3 index format, we should consider updating the publish API to tell the registry the version to use, and maybe more details about how to generate the index entry. This avoids forcing all registries to implement that logic.
        • But also be concerned about giving too much trust on the client.

2023-05-23

  • Edition 2024
    • https://github.com/orgs/rust-lang/projects/30/views/1
    • https://github.com/rust-lang/rfcs/pull/2801
    • doctest xcompile
      • https://github.com/rust-lang/cargo/issues/7040
      • Concerns about uncertainty about how much breakage it may cause.
      • Jacob: Try some tiered approach of phasing it in and see what kind of reports are given.
      • eric: Option to enable it nowish, off by default, so people don't need to wait 1.5 years.
      • weihang: is there an option to not fail the tests, show errors as warnings? Maybe say "this will be an error in the future", possibly with a specific version.
        • eric: concern that this might only show up in CI, and people may not be monitoring CI warnings.
      • eric: would like to solicit community feedback on what they think
    • https://github.com/orgs/rust-lang/projects/30/views/1?pane=issue&itemId=20026490
      • Transitioning out weak feature syntax
      • jacob: hard to teach, hard to re-teach
      • jacob: 10 years from now this goes away if we transition
      • eric: can work on an RFC for this
    • Optional dependencies not having an implicit feature.
      • Could be an error if there is nothing referring to dep: in the features table.
      • eric: wondering if you can just not have a feature, and then rely on cfg(accessible)
        • Error helps catch problems in transition
        • cfg(accessible) is limited to std-lib, at first
    • Pre-release requirements
      • https://github.com/rust-lang/cargo/issues/2222
      • Could potentially be a challenging project to figure out the desired semantics.
      • ed: treat all pre-releases as = since any change could be a breaking change.
      • jacob: there are other use cases that could be an issue. For example, some people won't make breaking changes, but their users won't easily know that they need to update (without cargo update).
      • Another request is to allow multiple pre-release versions to coexist. Using = can be a little challenging due to creating a rigid lockfile.
      • post-release versioning. What do forks or other scenarios with patching existing crates do with the version number.
    • End all transition periods when next edition comes out.
      • eric: also fine with just transitioning some of these now, particularly the ones that are several years old.
  • pushing down unstable features that are finished or almost finished. Are there things we can prioritize?
    • rustdoc collisions
    • eric: interested in:
    • ed: public/private dependencies
    • scott: cargo warnings
    • feature evolution:
      • For example, how can std evolve features?
      • libs team would like some focus this.
    • eric: very interested in cargo-semver checks.
      • eric: concern about getting rustdoc JSON stabilized
      • jacob: concern about the maintenance of trustfall
        • eric: we can freeze trustfall and maybe transition but thats al ot of work
  • RFC

2023-05-16

  • weihang: Add cargo help --commands — https://github.com/rust-lang/cargo/issues/12114
    • See also https://github.com/rust-lang/cargo/issues/12093
    • epage: splitting the conversation across two issues makes this a bit harder to follow
    • eric: why is this a separate flag from cargo --list?
      • Concern over breaking scripts which might be parsing --list.
      • Something similar to git help -a, which lists all commands.
    • ed: concern about adding topics to cargo help:
      • What has precedence, commands or topics?
    ​​​​$ git help -h
​​​​usage: git help [-a|--all] [--[no-]verbose]]
​​​​                [[-i|--info] [-m|--man] [-w|--web]] [<command>]
​​​​   or: git help [-g|--guides]
​​​​   or: git help [-c|--config]

​​​​    -a, --all             print all available commands
​​​​    -m, --man             show man page
​​​​    -w, --web             show manual in web browser
​​​​    -i, --info            show info page
​​​​    -v, --verbose         print command description
​​​​    -g, --guides          print list of useful guides
​​​​    -c, --config          print all configuration variable names

    ​​​​$ cargo doesntexist
​​​​error: no such command: `doesntexist`

​​​​    View all installed commands with `cargo --list`
    • keeping human-vs-machine readable commands separate
    • git help -a is different because its intention is that it is one of several flags for printing help topics, so suggesting it in "command not found" errors seems weird
    • machine-readable format for cargo --list flag --message=format=json
      • eric: concern that json is challenging to parse in a shell script, but some other format should be ok
    • Scott: suggestion of having cargo list subcommand, that can take various options for exactly how to return the output
      • or cargo query or whatever
        • Think of query language alt for cargo metadata
        • Maybe we could also have cargo state in there as well?
        • This is very far out there
    • Have transition period where our completion scripts support both
      • But we can't really test it
    • eric: what about just doing exactly what git help -a does, with a human-readable list of all things.
      • minor note: git help -g is separate for guides. Not sure why…
    • Use cases:
      • machine-readable
      • human-readable, I want to know what's there
      • human-readable, what I can get help about
    • weihang to follow up on the issue with some thoughts and questions
      • One fundamental question is whether or not to break cargo --list. We can update our own shell completions, but not others (fish, for example). And are there other use-cases? And even if we provide a compatibility window, users still need to know that they need to update their completions.
  • eric: recommendation around setting the documentation URL in Cargo.toml.
  • epage: Josh/Ed brainstorming: https://hackmd.io/tCpmm5VBTo6VPOusMdn1WA
  • arlo: credential process brainstorming
    • Goals:
      • Remove confusion between global credential helpers and crates-io's credential helper
        • Concern over possible way to leak credentials. A registry helper could be hard-coded to return crates.io key. Set that as the global, would leak the key to other registries.
      • Allow configuring multiple global credential helpers
        • NuGet, iterates until it finds one that works.
        • Pattern matching in URLs
      • Credential helper can include more specific failure information: "can't handle this request"
        • "i am the one that is supposed to handle this, don't try another"
      • Credential helper can include token expiration information
        • if there is a short-lived token, and a publish takes more than that time, cargo could fetch a new one
        • another kind of token is a one-shot, don't reuse or cache those.
      • Cargo can tell credential helper what operation token is needed for (publish / yank / etc)
        • Getting a signed token that is used for specific operations, like a publish-only token.
    • Change the protocol to use JSON messages.
      • eric: the current design was intended to work with other non-cargo credential helpers
        • You also need to be careful about needing user interaction (like how the 1password one works).
      • Versioning the interface between cargo and the tools.
        • If we want to make more changes in the future.
        • credential-process = "foo {version} …"
      • eric: The intent with {action} was to keep the configuration simple.
      • We can get rid of the "basic" protocol, and have an adapter that we ship, cargo-credential-shell, which does essentially what the basic one does.
    • Question about what changes can be made to unstable.
      • Most changes should be fine if they are in the spirit of the RFC. A complete rewrite might need an RFC. We can also make some breaking changes now, and do an RFC before stabilization.

2023-05-09

  • epage: Where to take office hours?
    • Two times people showed up but that was it
    • Post it in the Accepted issues?
    • Do a TWiR Call for Participation for our Accepted issues and include this?
    • Stop?
    • eric: suggest soliciting participation in TWiR based on issues interested in. Also make it clear that there is time available for people to get help.
      • ed: is also comfortable on talking with people on issues they are not familiar with.
    • weihang: live-coding presentation
  • weihang: Add support for jujutsu VCS — https://github.com/rust-lang/cargo/issues/12102
    • Sapling in a similar boat though no one has requested it
    • Internally used by Google. Author claimed it's their full time job at Google.
    • What is our criteria for adding other VCS support?
    • What we currently support:
      • cargo new knows how to create a new repo and write an ignore file
      • Whether or not a project is dirty (for example, for publish, fix)
      • Change tracking for fingerprinting
      • repository detection (to avoid walking every single one)
      • vcs file in .crate
      • git dependencies
    • Tiered support?
      • Supported, built-in to cargo
      • Supported, via some extension
      • Not supported
      • Support for different factors (cargo new, dirty tracking, dependencies, etc.)
    • josh:
      • Is it possible to have a datafile that indicates how to support any arbitrary vcs tool. The commands to run, etc.
      • This could potentially be specified in a cargo config file to point to the datafile that specifies how to support.
      • What does the path look like for going from third-party to first-party
      • Path to deprecation
    • jacob: Overlap with templates?
      • Choice of VCS can be independent of templates.
      • They would be orthogonal but can affect each other
    • Today
    • josh: Doesn't need to be fully general to start.
    • ed: Possibly incrementally working on refactoring the code towards a more general solution. An array of structs that have the interface needed for all the methods needed.
    • Possibilities around deprecating these tools? What is the stability guarantees?
    • Concerns around making a stable guarantee of support (indefinitely?) and what the status of this particular project is, and its popularity.
    • Josh: An RFC for simple config-based shouldn't be too complicated.
      • eric: not as confident that it can be simple.
    • Could these definitions be only for supporting cargo new?
    • eric will follow up with a comment about the possibilies of having an extension system, but it isn't a priority for the team to help with the design of that.
  • eric: Cargo as a git subtree (instead of submodule)
    • Intent is to be able to test unstable things in rust-lang/rust CI, to help prevent breakage on nightly.
    • It is also not clear if the interface for build-std will ever be stable.
    • Downsides: More work to do synchronizations. Uncertainty around tooling. Need people to monitor changes.
    • Josh: We could merge into rust-lang/rust repo, but if we're not going to do that, I don't think we should have cargo exist in two places as actual files rather than as a link (submodule) in one place. Too painful to merge.
    • Surprisingly this might be a rare case for submodules
    • Josh: On balance seems like a bad idea to have the files live in both places.
    • Do subtrees cause problems with current projects. Clippy, rustmft, rust-analyzer?
    • eric: Currently get a lot of notifications due to people having trouble with git. Not sure if subtrees will be better or worse.
      • If using a subtree, would want someone else to volunteer to monitor for changes on rust-lang/rust.
    • If changing, make sure to be clearly documented.
    • Two use cases:
      • Working with rust-lang/rust as a normal contributor
      • Syncing src/tools/cargo, which is a niche use for a small audience.
    • Eric: Question about the stability of std. If build-std is stabilized, is it possible to rely on std to be stable at that point.
      • Josh: Not making a guaratee that older cargos can build newer version.
      • Josh: Can't assume lockstep.
      • Not being able to make breaking changes is a feature, not a bug. The interface should be stable (in some narrow way).
      • Possibly versioning the interface, so breaking changes can be made, but in a backwards-compatible way.
    • Not necessarily a net win, since we still need to sync the changes from rust-lang/rust to rust-lang/cargo for Cargo's CI not to be broken in the next nightly.
    • Josh: preference for one canonical home for cargo.
    • Improving CI: beta's CI could not test on nightly, for example

2023-05-02

  • eric: Add a flag for keeping target directory on clean: https://github.com/rust-lang/cargo/pull/11888
    • cargo clean fails, why is this a problem?
    • Within their workflow, they always need it to be set within that project, so a flag is kind of iffy
    • possibly too specialized
    • If all is cleaned up inside, so what?
    • eric: They can make the target a directory within the mount
    • One potential route is to warn if target/ can't be deleted
      • Too magical and break other automation?
    • eric: will close since this doesn't seem like what we would like to do
  • weihang: Pass --cfg doc to check builds of dependencies as part of cargo doc/rustdoc: https://github.com/rust-lang/cargo/issues/8811
    • Wouldn't reuse cargo-check cache
    • Currently this is like --cfg test which is only for the final item
    • Would this break expectations
      • Yes, but could do crater run to check impact
    • Generalize build.rs problem for all cargo check uses?
    • Apparently not all is build.rs related
      • One comment is about language versions, so it seems like they should check the language version…
      • If there are shenanigans we are doing, then that is different
    • eric: will leave a comment with some questions to move the focus on the higher-level design
  • eh2406: https://github.com/rust-lang/cargo/pull/11937 in beta. What hapens if we make - => _ recommended in the index?
    • What is a possibility of using O(1) of the lookup?
    • Changing the index to have a canonical format that is used in the index so it would only need to look up two.
    • If using a canonical form, older versions of cargo would time out waiting to find the crate in the index. (with the above change, because previously cargo would search for different permutations)
    • A config.json flag to indicate if the registry is normalized.
    • Where is QueryKind::Exact being used?
    • We could just change the index format, and say some range of Cargo versions (starting in 1.70) can't publish (or do certain other commands?).
    • Other reasons for typos other than -/_.
    • An alternative is to query just exact, all underscores, all dashes.
      • Publish polling would triple the number of requests.
      • arlo: would prefer not to do that many requests
      • eric: questioning whether it matters, is that a significant amount of traffic?
    • Main motivation for canonical form allows cargo to not care, allowing the user to not have to care, either.
    • eric: Questions about the feasability of this working in such a way to be compatible with older versions of Cargo.
      • arlo and jacob think it should, though it may result in a lot of 404 traffic.
    • Leaning towards not doing anything for beta. If we implement normalization at some time in the future, there will just need to be some kind of compatibility notice about certain versions of cargo having issues.
    • eric: Thinks typo support on the server or index side could help with this dash/underscore issue.
  • Scott: Should cargo use [workspace.dependencies]?
Select a repo