---
robots: noindex, nofollow
tags: meetings
---

# Cargo team meeting notes 2022 H1

## 2022-06-28
- Release week
- Adding `[env]` support to subcommands: https://github.com/rust-lang/cargo/pull/10780
- Respond with what further discussion there should be, clarify next steps
- Josh will respond
- Roadmap
- Public roadmap: https://github.com/rust-lang/cargo/projects/1
- Was advertised in previous blog posts, but it is suspected that nobody but eric looks at it.
- Pointing people to “here’s a list of things we’d like to see work on and will review”
- Doesn’t help with the fundamental bottleneck of reviewing. Getting people to become familiar with subsections of cargo to the point where they would be capable of reviewing those subsections.
- Sparse index update
- Currently gathering feedback. No major concerns so far.
## 2022-06-21
- Working with out eric
- Document behavior in tests with “why”
- Librification would help to create isolated groups of knowledge rather than keeping everything in mind
- https://github.com/rust-lang/blog.rust-lang.org/pull/990 sparse-registry blog post
- See workspace inheritance’s testing section: https://this-week-in-rust.org/blog/2022/05/18/this-week-in-rust-443/
- Josh will help shepherd it
- https://github.com/rust-lang/cargo/pull/10771 Asymmetric tokens
- Contrib
- Jon’s team might be willing to help us out
- Need roadmap
- Ideas
- Documentation
- Lose features like cross-linking
- Prototype anyways
- https://hackmd.io/ZU8tu7ZTT-aF2FYJQOhxww?edit
## 2022-06-14
- Discussion about registry replace mechanism and publish (invite proposer to meeting?)
- https://hackmd.io/W3b7_km8RmGAxZ2qMJjfzg
- Reply with:
- No ambiguity
- disambiguate with publish/target
- RFC repo but don’t worry about the template structure (“guide-level”/”reference-level”)
- Warnings for duplicate packages (https://github.com/rust-lang/cargo/issues/10752)
- Fundamentally the problem is we are accessing all crates, even if they are “internal”
- git sources ignore workspaces
- C FFI crates have private crates for testing
- Restrict warning to not `publish = false`
- Have `Cargo.toml` flag to say “don’t recurse unless its part of workspace”
- Note: this should be different for `install` vs git dependencies; git dependencies should still search the repository, and warn if ambiguous, but `install` shouldn’t install every crate in a repository.
- A `.cargoignore` file for stopping recursing?
- Fuzzy finding in sources (https://github.com/rust-lang/cargo/issues/10729)
- Related: https://github.com/rust-lang/cargo/issues/10680
- fuzzy is values for error reporting
- Switch to Strict, Normalize, Error Candidates
- Note: Byron’s project grant was accepted (iirc preparing gitoxide for use in cargo)
- 🎉
- Note: Muscraft’s fellowship grant for making cargo more maintainable got approved
- Shoud we add Muscraft and Arlo to our meetings? Should we form a “cargo contributors” sub-team?
## 2022-06-07
- No Eric on 14th or 21st
- No Ed on 28th and 5th
- RustConf
- Josh, Ed
- No Jacob
- Eric is undecided
- Making `src` cache read-only
- https://github.com/rust-lang/cargo/issues/9455
- Problem Case: copy read-only and then modifying it
- Ideas for incremental introduction
- All new publishes
- verify build should identify the problem
- Edition boundary
- Flag or opt-in to say “don’t mark read-only”
- Crater run to determine scale?
- It’s a bit difficult to test cargo changes, but they can be faked.
- HTTP registries
- https://github.com/rust-lang/cargo/issues/10722
- The UX for opting in to an HTTP registry
- Currently: -Z flag, which allows you to explicitly opt-in with `sparse+` URL.
- Specifying `sparse+` URL in source replacement, or source for an alt registry
- Plain HTTP auto-detect.
- Try a git fetch or http request to automatically determine which it supports.
- `registry+https://…` is always git-based
- `sparse+https://…` is always http-based
- Expected UX for allowing users to decide crates.io access
- If only needed by some rare scenarios like crater, then `-Z` is fine for them.
- Need to figure out what the use cases are.
- Needs for pre-fetching the index, or firewall or proxy issues, etc.
- Use source replacements? Already works today.
- https://github.com/rust-lang/cargo/pull/10725
- Makes `-Z http-registry` use index.crates.io automatically without needing soure replacement.
- Publish behavior
- https://github.com/rust-lang/cargo/pull/10725
- We can have hard-coded checks for crates.io so that source-replacement of git↔http works
- Authentication behavior with source replacement
- The replacement server cold proxy the publish out to crates.io
- Some kind of flag to `cargo publish` to explicitly tell cargo how to behave with source-replacement? `--replacement=follow`?
- Less of security concern with asymmetric tokens.
- `cargo publish` can just look at the `api` key of the index to know where to publish. In a source-replaced world, that would likely be `https://crates.io`. Then just use the token configured for `crates.io`.
- In theory, a mirror could change the `api` key to go somewhere else to relay to crates.io
- Authenticated download behavior with source replacement
- Only use asymmetric with authenticated download
- How do you specify the token for a replaced source?
- The authentication information should be keyed on the URL?
- The TOML is still organized by registry name.
- Checks to ensure there aren’t more than one registry with the same URL.
- Should publish ignore replacement?
- That is, disable replacement. Or keep replacement and just honor whatever API it tells us to use?
- B replaces A
- `cargo publish` options:
- error
- Ignore source replacement using A’s credentials, ignoring B.
- And tell the user
- Which steps are ignored?
- The index, downloading dependencies, etc. still use replacement.
- Just the API to publish does not use the replacement.
- The API URL also needs to come from somewhere.
- Using crates.io can be hard-coded.

## 2022-05-31
- https://github.com/rust-lang/cargo/issues/10714
- add target triple to proc-macros
- The `proc-macro` crate could provide this information.
- concern: using `std::env::var` would prevent cargo from rebuilding the proc-macro correctly. `env!` would work
- alternatives:
- generate code for all targets (with `#[cfg]` to separate them out)
- Close as something that should probably be part of rustc/proc-macro
- https://github.com/rust-lang/cargo/pull/10716
- read-only Cargo.lock
- propose to close
- https://github.com/rust-lang/cargo/pull/10663
- add description for `cargo` `--``list`
- No longer need to hard code `cargo clippy` and `cargo fmt`
- Allow moving more commands out of cargo without hard coding them
- Use manifest description?
- Not written for that purpose?
- Ask the command?
- Security concerns if the command doesn’t support the flag and its unknown what the command will do
- More extensible embedded metadata (could be used for other information for different integration concerns).
- Or have the note indicate the sorts of CLI arguments the command supports (“supports cargo CLI API v1”, and then `--_cargo_description` works)
- Other metadata like dependency versions (https://github.com/rust-lang/rfcs/pull/2801) (that is a bit different, though)
- Have the command opt-in through the metadata
- Would users be concerned that we’d be running commands that they haven’t specifically invoked?
- Problem with elf note is its format-specific
- Will fail with shell script commands. Ed uses this to run commands out of master
- Can PE support it?
- Alt: allow opt-ing in to what the description should be used
- How to do self-install
- propose to close
- need tier 1 targets supported
- need support for alternative executables (like scripts)
- Can’t design atm
- https://github.com/rust-lang/cargo/pull/10493
- turn off debuginfo for build dependencies
- https://docs.google.com/spreadsheets/d/1lru9ibjHLaXdFbROFIZXcvzXBKDDewGXjRYuvwJ0Xp8/edit#gid=0
- Not a clear win across the board. Doing duplicate builds (debuginfo on/off), would prefer to conslidate them.
- Not much available time to focus on this change.
- Could possibly add an unstable option to allow random people to test it themselves.
- Or, people could just add the appropriate profile option (`profile.dev.build-dependencies.debug = 0`)
-
- https://github.com/rust-lang/cargo/pull/10713
- Any practice for env variables
- env variables are added in an as-needed basis
- https://github.com/rust-lang/cargo/pull/10717
- Change to respect submodule update=none
- Reject? I’m assuming this is intentional
- https://github.com/rust-lang/cargo/issues/4247
- Needs a test
- Yes, respect the config. Its people’s fault if it break them
- Foundation hiring, discussion about administrative help
## 2022-05-24
- https://github.com/rust-lang/git2-rs/issues/838
- Related: https://github.com/rust-lang/cargo/issues/10623
- Options
- Ideal would require pubgrub for good error
- Bool flag threaded through
- Minimal error message for rust-version?
- Just add to error message “could be msrv”
- When do people see version resolution message
- `cargo publish` not waiting for crate to show up in the registry, so a subsequent publish of a crate depending on it can error out.
- https://github.com/rust-lang/cargo/issues/9507
- Typo or equivalent in Cargo.toml
- https://github.com/rust-lang/cargo/issues/10599
- Wants to have a version range across multiple semver-incompatible versions.
- This can result in multiple dependencies (which are type-incompatible).
- proposal:
- diesel wants to support uuid 0.8 to 1.x. The range causes cargo to select the newest for diesel, but other packages might use an older version.
- With public/private dependencies, cargo would know that these two uuid’s need to be unified.
- Use case: upgrade public dependencies without a breaking change
- eric to respond
- https://github.com/rust-lang/cargo/issues/10604
- Wants to depend on different semver-compatible versions of a package based on features.
- proposal: won’t fix
- this is a way of mutually exclusive features
- one problem with this is the lock file for the project in question is the lock file is generated for all features and errors
- Will work for dependents
- crates.io S3 bucket is set up for http registry
- Making `-Z` defult to enable without the config
- Discussed opt-out functionality
## 2022-05-17
- Getting an associate fellow grant for a person to help?
- Ed is helping with grant review
- Reaching out to the foundation
- Favoring grants that’ll make Cargo more sustainable
- Various other projects could help cargo (like pubgrub)
- TWiR adding a “call for testing” section
- [Path to sustainability](https://hackmd.io/@-V_VxI2XQpeKK6qVyIMTSw/Hk9ff5WLc/edit)
- Promoting the things the team is actually interested in
- The roadmap https://github.com/rust-lang/cargo/projects/1 was intended to communicate which of the big ideas the team was interested in.
- Difficult to get people involved in a “stuck” project
- Needs caveats that these are theories
- Ask for feedback on things like rust-semverver
- Where to post:
- inside-rust blog
- The kinds of projects that actually help (gitoxide, pubgrub, crate-api, etc.) vs ones that mostly put more burden on us (new features).
- Separate projects is one aspect of that
- Separate maintenance team helps a great deal
- Without componentization, changes touch everything and need global knowledge
- Downside to reuse is if still maintained by cargo team, then we take on maintenance burden of everyone else’s usage and use cases
- Capturing some of the meta-principles.
- Split out components that will be maintained by others, rather than maintained by us which means we are taking on maintaining for everyone else
- Implement RFC 3139: questions, https://github.com/rust-lang/cargo/pull/10592#issuecomment-1128193694
- Asking to look at some questions regarding the PR
## 2022-05-10
- Expectations for stabilizing a feature like workspace inheritance?
- https://github.com/rust-lang/cargo/issues/8415
- https://github.com/rust-lang/cargo/issues/8415#issuecomment-1112618913
- https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance
- Call for feedback on public forums (reddit or users or twitter or whatever)
- Musecraft may be able to do this
- Add a section to TWIR for things to test or try out, request for feedback
- Try to keep each weeks list small (1-2 at most)
- Or just part of “Call for Participation”
- Demo within projects
- Demo clap PR
- Use within rustc (rust-lang/rust) itself
- There are edge cases that cause problems
- Wait for being in bootstrap?
- cargo does accept RUSTC_BOOTSTRAP=1
- [https://github.com/rust-lang/cargo/pull/10567](https://github.com/rust-lang/cargo/pull/10567)
- checkboxes for timing config
- consistency of config versus CLI, where CLI options are still unstable.
- Could use true/false as config option
- Eric’s preference is to keep the config simple (since it will be rarely used), but this is definitely an option
- Or, allow `--timings=html`.
- concern that config-file based settings can be difficult to deal with in scripting situations where there is an implicit behavior change that is not directly tied to the cargo invocation
- https://github.com/rust-lang/cargo/pull/10308
- Move build-std to Cargo.toml
- Eric: concern about this being a global project-wide choice
- Make it a profile option
- The original vision was to have a single global true/false, and some point in the future make the default `true`
- Discussed the difficulties and complexities of that (such as compiler-builtins C impl versus Rust impl, sanitizers, feature selection stability, target-specific requirements needing C libraries and funky linker issues, etc.)
- Std with specific features or compiler options
- Cargo.toml dependencies on std
- During wg-cargo-std-aware, attempts to make that work hit too many issues, particularly around implicit effects
- Versioning of features
- eric is skeptical that features in std can ever be stabilized
- https://github.com/rust-lang/rfcs/pull/3146
- josh feels like some kind of versioning is viable
- Final destination of having build-std enabled by default
- Is there a way to make steps along that road that work with the future goals?
- If it is really necessary to have per-target build-std, then one option is to just enhance the config file to allow enabling it per-target.
## 2022-05-03
- Snapbox and cargo: https://github.com/rust-lang/cargo/pull/10620
- cargo tree would be good with filesystem snapshotting
- Switching to `snapbox::cmd::Command::cargo()` API etc. seems like a good idea to keep a single API and start moving away from the old way
- epage: <name>.in → <name>/in for grouping in IDE and no copy/rename scripts
- epage: write up documentation saying when to use what
- epage: new proc macro for test discovery
- change detection
- tracked path api is unstable
- include magic?
- ehuss to pass it along
- https://github.com/rust-lang/rust/issues/73921 — `const` or `build.rs`
- overwriting snapshots will preserve wildcards where possible
- how to handle and arrange a test case the invokes `cargo build` several times?
- Use a naming convention to specify the seperate steps (number them in sequence or whatever)
- docs:
- writing new tests
- multiple bin calls to verify in a test
- updating tests
- https://github.com/rust-lang/cargo/pull/10493
- Remove debuginfo for build scripts
- eric has performed a bunch of benchmarks locally, but still needs more time to make it presentable
- avg 4 or 8 cpus from survey
- 95+% have 4+ cpu threads.
- optimize for individual developer vs corp environment
- CI runners are 2 cores: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#cloud-hosts-for-github-hosted-runners
- future-incompat and pkgid syntax: https://github.com/rust-lang/cargo/pull/10582
- the pkgid is stored as-is in disk, and uses that as a key for showing the report with `cargo report future-incomat -p ID`
- No guarentee for on disk format
- Nightly and stable work together?
- We do this for lock files but that is expected to be used for both (its persistent) vs a pairing of commands
- Parse both syntaxes?
- Bump format version?
- eric: recommend not doing anything, but up to ed if they want to
- https://github.com/rust-lang/cargo/pull/10344 - cancel FCP while waiting for author?
- Has been closed
- Cargo’s startup time in git2/openssl initialization
- using openssl_dynamic sounds reasonable if it works, ssh initialization needs some work
- https://github.com/rust-lang/cargo/issues/10623
- error message with libgit2-sys wasn’t good
- resolver doesn’t tell you why it ignored certain versions
## 2022-04-12
- Ed’s comments on getting more help.
- https://github.com/rust-lang/cargo/issues/10446
- New release 0.60.1 of stable with libgit2 updated
- eric to comment that its ok, someone needs to post a PR
- https://github.com/rust-lang/cargo/issues/10543
- `cargo metadata` in 1.60 changed how features are exposed. Optional dependencies are now included in the “features” table when they weren’t before.
- Understandable that it broke some usage, it removed the ability to determine which features are explicitly listed in the `[features]` table. However, optional dependences *are* features, and ignoring them is arguably wrong.
- Optional dependencies are not always intended to be features under the old syntax and takes time for people to upgrade their MSRV
- Tell if they used the new mechanism?
- Too late for transition plan, will go away in 6 months?
- Limited dev time, might take a while to create a transition plan
- But no forcing function for crate authors to adopt; they aren’t directly impacted by tooling changes
- Show raw data in cargo-metadata
- Would people want unresolved manfiests?
- Getting too much information in it? Should we provide a query syntax, like GraphQL
- New format version?
- Can we pass it along? Yes, because we track it for the index
- A lot of work for people to update
- What about people relying on the 1.60 behavior?
- What design?
- “implicit” flag
- Current field is raw, new resolved features field
- Field that is list of implicit (or explicit?) feature-dependency
- ehuss to comment and see if manish has ideas, and propose some and discuss the difficulties
- [https://github.com/rust-lang/cargo/issues/10540](https://github.com/rust-lang/cargo/issues/10540)
- The user would like use the new `?/` features syntax everywhere.
- eric would like to move to close. Was designed to have `?` related to being “optional” similar to Rust options.
- Could be confusing, reading might appear to be optional.
- Is there some way we can get rid of the `?/` syntax?
- Edition 2024: Remove `?/` and `/` behaves like `?/`.
- Eric to open an issue for that to consider in a year or two.
- With toml_edit, `cargo fix` can automatically fix things.
- ed: confusion about `dep:foo` vs `foo/bar`. Why not `dep:foo/bar`?
- Consistent with CLI
- https://github.com/rust-lang/cargo/issues/10531
- Remove `#[cfg(test)] mod tests {}` from `cargo new`
- For many tests, a separate module is not necessary (just adds indentation, noise, etc.)
- Best practices
- Any time you need a helper function, `use` imports, etc, you then need to start adding `#[cfg(test)]`, which can be confusing.
- `mod tests;` can be better since it can reduce recompilation in some cases
- Adding a new file could be much more cumbersome.
- What is the ultimate best practice?
- This is a wider conversation.
- What is the best getting started?
- What is the best for teaching a new user?
- The existing thing helps teach about `#[cfg(test)]` which was important for me
- Code folding works better with a module.
- Defer to a cargo-generate?
- Should we consider merging something like this into cargo-new?
- Worth looking at lessons learned from Python’s use of cookie-cutter
- https://github.com/rust-lang/cargo/pull/10492
- Add a link to the documentation in the `--timings` report
- Where to put link?
- Currently in header
- Below h1
- See Documentation italized
- [https://github.com/rust-lang/cargo/pull/10432](https://github.com/rust-lang/cargo/pull/10432)
- Disallow enabling debuginfo while stripping it
- Previously said a warning would be fine
- inheritance can make it a little complicated
- also check if split-debuginfo is “packed” and not warn? That might be a legitimate use case.
- https://github.com/rust-lang/cargo/pull/10493
- Remove debuginfo for build scripts
- Sharing builds has caused lots of problems and could help to get rid of
- ehuss is seeing mixed performance results
- debug: i-dont-care
- Share if possible. If not shared, then build without debuginfo.
## 2022-04-05
- Call for contributors / soft-roadmap?
- roadmap might be too much, as it might advertise people to do work we don’t have capacity for
- things that are helpful: reviewing, triaging, summarizing, helping with cleanup, detailed work
- eric: a process similar to lang/compiler team MCP, where there is a liason committed to the work
- balance of liason doing too much work
- reacting to people coming in with things they want to do, versus proactive for things the team wants to see done
- Where can I help? Not an easy answer.
- Making things more maintainable, or take things off our plates.
- Are there areas where we could point people to for doing general code improvements?
- Downcasting error types?
- https://github.com/rust-lang/cargo/issues/10160
- PR was rejected: https://github.com/rust-lang/cargo/pull/10163
- `Resolve` has two sources (one from Cargo.lock, or one from performing resolution). It has different properties based on where it came from. This isn’t terribly good. Requires good judgement on how to design the types. An enum, multiple types, keep the current design… several different approaches.
- Issue triage
- Sync?
- FCP bot?
- Move to close proposal and have someone else close
- Using the weekly meeting to discuss issues (should this be closed, should we accept this, etc.) Useful if you are in doubt about something, or want to see some feature-request accepted.
- cargo-add redux
## 2022-03-29
- cargo-add: https://github.com/rust-lang/cargo/pull/10472
- Positional arguments
- `cargo add serde -F serde/derive tokio rand`
- Path arguments
- concern about ambiguity
- path support unstable for more time to think about the interface
- Options for stabilization
- Stabilize `cargo add <dep_or_path>` only, everything else -Z
- If this shadows a user’s `cargo-edit`, this could block them from using any features behind a `-Z` flag
- Suggest `cargo install cargo-edit && cargo uadd`
- RUSTC_BOOTSTRAP, and auto-passes `-Zunstable-options`
- Add as `cargo zadd` only on nightly.
- This provides an opportunity to experiment before comitting.
- Concern that nobody would use the nightly version
- Add as `cargo add -Zunstable-options …`
- This sounds terrible
- Add as `cargo add -Zunstable-options …`, but don’t shadow user-installed cargo-edit
-
- Stabilize as-is
- git: Having a bunch of flags versus a more concise syntax
- `--git URI package_name`, problem with how to handle multiple dependency names
- https://github.com/killercup/cargo-edit/pull/586
- needs some design work
- `cargo add git+<url>#branch=dev`
- `cargo add` `--``git <url>` `--``branch <dev>`
- install parallels:
- One difference is install runs isolated of the workspace while add takes into account the workspace
- merge https://github.com/rust-lang/rfcs/pull/3231
- eric will merge
- github discussion: https://github.com/rust-lang/cargo/issues/10510
- eric will close for now
- think about `dl` per versions https://github.com/rust-lang/cargo/pull/10484
- probably needs RFC, jacob will respond
## 2022-03-22
- Discussing PR triage
## 2022-03-15
- Move meeting one hour later
- Move to Tuesday 9am pacific
- Discuss review capacity
- Publically stating that the team does not have the capacity for reviews
- blog post
- Stating in the README
- PR template
- Feature request issue template
- Pinning an issue
- Onboarding and helping
- esoteric or specialized knowledge, niche problems
- breaking up and modularization.
- People can be focused on particular areas to help, rather than knowing everything about cargo
- resolver is subtle and difficult to work with
- pubgrub could change that complexity to offload to something else
- consider a contributor team
- build-override defaults:
- https://github.com/lqd/cargo/commit/f6cfe00baa8bb06bc83bc735e3e7a9ff9bc75d1c
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Defaults.20for.20faster.20compilation.20of.20.22for.20host.22.20units
- Effect on backtraces
- I think it will end up showing just symbols instead of line info, which could make it harder to debug panics.
- If RUST_BACKTRACE is set, could display a message to hint to the user to enable debuginfo to get more information
- Compatibility of `strip`
- This isn’t a significant performance win, mostly a disk space savings
- Could maybe be dropped
- Concern that `strip` has not been exercised significantly across many platforms, so may encounter some issues.
- Effects of incremental
- Most build scripts are tiny, which probably won’t benefit from incremental
- A drawback for people working on larger build scripts.
- Might be good to measure the impact on minor changes to a build script.
- Can we FCP: https://github.com/rust-lang/rfcs/pull/3231
- No feedback in the past 3 weeks
- How to review “HTTP registry implementation” https://github.com/rust-lang/cargo/pull/10470
## 2022-03-08
- Followup on GitHub index usage
- Should prioritize http registry usage
- https://github.com/rust-lang/cargo/pull/8890 — stalled PR
- Hopefully make substantial progress this year
- [https://github.com/rust-lang/cargo/issues/7617](https://github.com/rust-lang/cargo/issues/7617)
- Refresh index config after downloading
- Broadcasting for help?
- https://github.com/rust-lang/cargo/issues/10455
- recognize $PATHEXT on windows for cargo subcommands
- If there is an easy fix for .bat/.cmd, that might be ok. If std::process::Command can’t handle it, then that would be a blocker. Can maybe delegate PATH search to it as well.
- josh to respond
- [https://github.com/rust-lang/cargo/pull/10432](https://github.com/rust-lang/cargo/pull/10432)
- Disallow debuginfo + strip in a profile
- josh: a warning might be useful
- [https://github.com/rust-lang/cargo/pull/10438](https://github.com/rust-lang/cargo/pull/10438)
- deny clippy lints in CI
- Current situation is not great
- josh: have clippy have a message saying not to submit clippy PRs
- clippy isn’t allowed due to false positives, excessive enabled lints, hassle with contributing, new lints appear every release, arbitrary style choices
- eric: don’t check on CI and disable the 2 lints, they aren’t super valuable
- [https://github.com/rust-lang/cargo/pull/10414](https://github.com/rust-lang/cargo/pull/10414)
- Exposing more pub internals
- Ask for the actual problem
- eric: Ok with a few pub, but some of this is intrusive, and exposing very low-level internals
- https://github.com/rust-lang/cargo/issues/10457
- Mark ~/.cargo or some subdirectories with CACHEDIR.TAG
- libgit2 system shared dependency
- eric: propose moving forward with current PR to constrain to 1.4, then some time in the future in a semver major change, swap the opt-in/out-out behavior
- josh: having a global opt-in/out-out instead of per-crate custom logic
- josh: try to stay with some commonly used variable
- Are we ok with adding a `-C` which changes the current working directory.
- josh: try to make the semantics very clear
- Call `chdir` first, in main, before doing anything else (including reading config)
- config should be read after change
- CLI arguments are relative to *after* `-C`
- eric: feels like a hack, but I see how it can be useful
- eric to comment or open new issue
- https://github.com/rust-lang/cargo/issues/10098
- Policy on nightly > nightly
- https://github.com/rust-lang/cargo/pull/10427
## 2022-03-01
- https://github.com/rust-lang/cargo/pull/10344
- multi-source vendor directory layout
- clarifying the situation
- [https://github.com/rust-lang/cargo/issues/10430](https://github.com/rust-lang/cargo/issues/10430)
- Allow for a way to package and sign executables
- josh to close
- https://github.com/rust-lang/cargo/pull/10322
- Test if reserved filenames are allowed in Windows
- Just wondering if anyone has access to Windows 11
- https://github.com/rust-lang/cargo/pull/10435
- doc-dependencies
- Example use case:
- https://github.com/baoyachi/shadow-rs/blob/master/src/lib.rs#L81
- https://github.com/baoyachi/shadow-rs/blob/master/Cargo.toml#L18
- Alternatives
- Profile?
- Treat like a target?
- assuming we add default features for cargo-targets
- per-command default features (like default for `cargo doc` or `cargo test`)
- Essentially making `package.metadata.docs.rs.features` a more fundamental thing.
- Ed’s examples above using cfg_attr
- https://doc.crates.io/contrib/process/working-on-cargo.html should direct the reader to “Process”
## 2022-02-22
- Big 1.59 release on Thursday for both cargo and rustc
- Massive cheers for ehuss on artifact dependencies
- `target-applies-to-host`
- https://github.com/rust-lang/cargo/pull/10395
- auth RFCs
- More authenticated endpoints: https://github.com/rust-lang/rfcs/pull/3139
- Add that it is dependent on 3231, will post a comment with the kind of text to add
- Asymmetric tokens: https://github.com/rust-lang/rfcs/pull/3231
- What is the path to FCP?
- Possibly wait until there aren’t any significant new comments for a few weeks before starting FCP.
- https://github.com/rust-lang/cargo/pull/10369
- Pulling in new dependencies. (heck, proc-macro-error, proc-macro-error-attr)
- Using derive macros for arguments?
- Challenges:
- Customization: see an example: https://docs.rs/clap-verbosity-flag/latest/clap_verbosity_flag/
- Grab back processing (commands define a subset of arguments read)
- Benefits
- Leverage type system
- Less “stringly typed”
- Clap does want to improve this with builder, like https://github.com/clap-rs/clap/issues/2683
- Automatically leverage more of clap

## 2022-02-15
- Index squashing
- waiting for GitHub to respond on keeping 1 branch around or some other workaround to ensure that incremental updates continue working
- Uncertain if they will be squashing next week, or just removing the branches
- This would be good to know
- Consequence of having thousands of downloads happening on the same day of the entire repo (unlikely to be a real concern, but might be good to clarify)
- Index is currently ~120MB (squashing would probably be around half? last squash was Dec 21)
- http registries will alleviate here
- Jacob to follow up (posted asking for a meeting on their discord)
- macOS strip
- https://github.com/rust-lang/rust/issues/93988
- Possibly not strip for build script and proc-macros?
- Possibly make `strip=true` be `strip=debuginfo` for dynamic libraries on macOS?
- response files
- https://github.com/rust-lang/cargo/issues/10381
- https://docs.rs/argfile/latest/argfile/
- security token auth RFC
- https://github.com/rust-lang/rfcs/pull/3231
- Discussing some of the UX
- token scopes might still be able to be done independently: https://github.com/rust-lang/rfcs/pull/2947
- https://github.com/rust-lang/rfcs/pull/3139 can still be done, but there is a tie in here where 3139 enables more endpoints, and 3231 specifies which method is used for those endpoints
## 2022-02-08
- cargo auth RFC
- RFC token to more endpoints (RFC as-is)
- asymmetric RFC separately, posting soon
- https://github.com/rust-lang/cargo/issues/10321 — RUSTFLAGS not set in build scripts
- Possible duplicate of https://github.com/rust-lang/cargo/issues/10111
- Detect scenario where spaces would be a problem, and unset RUSTFLAGS in that scenario.
- If RUSTFLAGS and `build.rustflags` is set, which one does it see?
- Was changed in 1.55 (July)
- Josh will respond
- artifact dependencies in the index
[dependencies]
foo = {version="1", target="wasm32-wasi", artifact="bin:foo"}
- Should `target` be in the index?
- Feature resolution needs to know the `target`
- Seems fine to add to the index
- Drawback: can’t test on crates.io until we commit to this format and get crates.io updated. Workaround is to use git dependencies, or vendoring or local paths, etc.
## 2022-02-01
- rustix - https://github.com/rust-lang/cargo/pull/10309
- josh to comment
- perhaps a bit early to pick up rustix? (it’s a pretty new thing)
- goal of rustix is I/O lifetimes with safe access to many posix functions
- PR queue discussion
- various ideas about closing
- generally how to free things up and have less of a logjam
- Encourage Issue-first?
- epage to do quick triage for stale
- Clarify contributing guidelines - should probably update `CONTRIBUTING.md`
- RFC 3191 https://github.com/rust-lang/rfcs/pull/3191 Natvis support
#[debug(natvis = include_str!("Foo.natvis"))]
pub struct Foo {...}
- https://github.com/rust-lang/rfcs/pull/3191#issuecomment-1023510859
- No objection to having natvis support at a high level
- Unclear whether this sort of information is part of code/attributes or part of cargo’s configuration
- `-Ztimings` https://github.com/rust-lang/cargo/pull/10245
## 2022-01-25
- security policy for cargo itself
- general policy: each issue should be reported to the security team, and then evaluated on case-by-case
- cargo has to trust build scripts and proc-macros
- threat model: two local users, and cargo helps one user attack the other
- remove_dir_all:
- cargo has its own custom implementation for better errors and changing permissions.
- probably not a security risk immediately
- split-debuginfo doesn’t work with gdb on macos
- https://www.reddit.com/r/rust/comments/sadfzr/macos_gdb_and_cargo/
- (eric) I think it requires typing a command to tell gdb where to search for .o files
- eric to file an issue for docs or something
- tagging milestones for PRs
- consider using GitHub Actions to further automate it
- piggybacking on triagebot
- https://github.com/rust-lang/cargo/pull/10313
- eric: a little uncomfortable ignoring it
- josh: noisily send a message, or an error with a note on how to work around it
- target-applies-to-host stabilization
- josh responding
- cargo-add: Venue for cargo-add merge proposal (interested in CLI design feedback, so wider?)
- Maybe posting to internals for feedback?
- Draft proposal to merge: https://github.com/killercup/cargo-edit/issues/568
- epage: team direction and where I can help?
- Build up on reviews
- Continue with cargo-edit, and maybe a cargo registry command
- Holding off on modularization because of lack of workspace-in-workspace
- Led to discuss cargo registry command
- RFC 3191 https://github.com/rust-lang/rfcs/pull/3191 Natvis support
- Nick is interested in moving towards merging, feel free to comment if you have a chance, will talk more next week
## 2022-01-18
- Things depending on themselves as a path dependency (take 2)
- Jacob summary of the situation https://github.com/rust-lang/cargo/issues/9518#issuecomment-1015073783
- Will put on pause for now, since it isn’t a pressing issue. In the future we would like to ban this, but can’t for now. Will want some kind of workaround (force-enable of features for tests), but that is a long ways off.
[ ] Jacob to respond (oops. I forgot. I will get to it)
- rust-lang/ci timeouts
- [https://github.com/rust-lang/cargo/pull/10245](https://github.com/rust-lang/cargo/pull/10245)
- -Z timings
- `--timings` places the report in `target/cargo-timings`
- JSON output is still unstable
- May prefer output to a file instead of stdout
- Other questions about its format
- Storing raw data in CARGO_HOME
- using a config option vs cli?
- supporting rustc self timings in the future
[ ] alex to review and to move to fcp
- https://github.com/rust-lang/cargo/pull/10274
- Adding more rustc-link-arg things to build scripts so you can set linker arguments for tests or examples
- skipping -Z unstable
- OK with FCP
- It does seem a little awkward to have a lot of these options, as it is unlikely many people will want to control each one independently.
- However, it isn’t a large drawback to support them
- [https://github.com/rust-lang/cargo/pull/10232](https://github.com/rust-lang/cargo/pull/10232)
- RUSTFLAGS space splitting quoting
- `CARGO_ENCODED_RUSTFLAGS` provides a way to handle flags with spaces
[ ] alex to close
- Would TOML ever be a solution?
- Possibly?
- `CARGO_BUILD_RUSTFLAGS=``'``[``"``foo bar``"``,` `"``abc``"``]``'`
- [https://github.com/rust-lang/cargo/pull/10276](https://github.com/rust-lang/cargo/pull/10276)
- semver guidelines for repr
- ehuss: Make it clear that this list is not exhaustive
- josh can help with second review

## 2022-01-11
- Things depending on themselves as a path dependency
- https://github.com/rust-lang/cargo/issues/9518#issuecomment-1008232010
- https://github.com/rust-lang/cargo/pull/9702
- If possible, implementing https://github.com/rust-lang/rfcs/pull/3020 would be a good alternative (automatically enabling certain features for tests) before making this an error.
- Jacob will try to investigate why the original issue was opened, why breaks or why does it not work as people think it is?
- namespaced and weak features - https://github.com/rust-lang/cargo/pull/10269
- Alex will do final review
- Artifact dependencies ready for review - https://github.com/rust-lang/cargo/pull/9992
- **huge** PR that is difficult to review
- clap3 - https://github.com/rust-lang/cargo/pull/10265
- ehuss: would have preferred to wait a few months before switching, but not critical
- epage knows clap very well, and has been responsive to issues
- Josh will take review
- toml_edit - https://github.com/rust-lang/cargo/pull/10086
- *someone* needs to do a full review of toml_edit itself, which is a big task
- Josh will help review toml_edit
- We need to figure out ways to help scale the availability of knowledge that only Eric and Alex have at the moment

## 2022-01-04
- [https://github.com/rust-lang/cargo/pull/10088](https://github.com/rust-lang/cargo/pull/10088)
- strip in profile
- stripping in release mode by default
- getting more experienced before changing defaults
- [https://github.com/rust-lang/cargo/pull/10135](https://github.com/rust-lang/cargo/pull/10135)
- including path deps in vendor
- uncertain if source replacement can handle paths
- ehuss: ask for feedback in the issue for use case
- [https://github.com/rust-lang/cargo/pull/10232](https://github.com/rust-lang/cargo/pull/10232)
- Splitting RUSTFLAGS on spaces
- don’t want to deal with pseudo-shell syntax, which might not match different shell syntaxes
- recommend `config.toml` or `--config` or `-Z advanced-env` try them out and review them
- [https://github.com/rust-lang/cargo/pull/10236](https://github.com/rust-lang/cargo/pull/10236)
- progress for clean
- concerns about progress, but alex already responded
- parallel removal can help with performance
- rustup has optimized the file delete path
- Evaluating performance for last-use tracking
- eric’s experiments show a concerning performance hit when tracking with sqlite
- touching mtimes can cause problems in docker
- Detecting if in a container can be a pain, and having environment-based differences can also be a pain
- atime granularity
- [https://github.com/rust-lang/cargo/pull/10245](https://github.com/rust-lang/cargo/pull/10245)
- stabilizing -Z timings
- Interface:
- Would it be possible to turn it on always, and not require a flag?
- Output location:
- josh’s concern about putting it in the `target` directory.
- run experiment 1; cargo clean; run experiment 2; cargo clean
- This would lose the results of the first experiment
- Always put it in `target`, and then an option could copy it out to cwd.
- enables rmeta required, which can be a significant hit
- we can probably just disable that, it’s just needed to get the codegen message
- would be great to extend rustc to emit more json messages (starting codegen, starting linking, etc.)
- using timing data for scheduling