Cargo team meeting notes 2024 Q2

2024-06-25

out: epage

Project Goals for Cargo?
- Are there projects Cargo wants to put on the roadmap, that potentially need coordinating with other teams, or that people may want to get a visible commitment on before starting to work on (e.g. because they want to get approval from their employer to spend time on them)?
- weihang: what is the timeframe to submit goals?
  - josh: fuzzily in the next week or two
- eric: clarifying, can goals just be within a team?
  - josh: yes.
- weihang: raising visibility in the community and within companies.
- https://rust-lang.github.io/rust-project-goals/2024h2/candidates.html
- jacob: when possible, it would be great to have pluggable cargo cache support.
- josh: In the future, we are looking at having the ability to put out a goal without an owner. It would include a rough sketch of the requirements we want.
- weihang: mentioned someone is willing to contribute cargo cache support. Unsure if we can guide them as mentors, and if they can commit to the goal.
  - josh: The success of the goal depends on the owner driving it forward (not the team pushing it). If the owner disappears, it essentially stops. That effectively then becomes "we need a new owner".
  - josh: a team member can be an owner if it is something they want to drive forward.
- jacob: projects without an owner, would be nice to track which projects are in that status. The wording around that really matters.
  - josh: "a goal in need of an owner", how to pitch that is not yet clear.
  - jacob: Thinking about updates on project announcements. Would like to have those to include things that are open, that need someone to pick them up.
    - jacob: And a link to a passive list, so the teams don't need to put in effort to put those goals out there.
  - jacob: Thinking of PubGrub seems kind of like a goal. Does that need a document to express that?
    - josh: because it is a major thing for cargo, it seems to fit the system very well, but if it doesn't seem to have value being on a roadmap, then that's fine. If it would help with your employer, then that would be a good reason to include it.
- weihang: idea would be sandbox build script. It needs some cross-team collaboration with proc-macro sandbox. That could help with talking with people of proc-macro sandbox, and thinking of the configuration together, and needs some visibility.
  - josh: seems like a great candidate in multiple ways. Is that something you are working on?
  - weihang: it's a bit odd… whether I can work on it. Which one should come first?
  - josh: Approval from Rust is exactly the benefit to make it easier to get corporate support.
- scott: Would throw out annotate-snippets as something for the long run, but that has already been solved to some degree.
- arlo: documentation for features. cross-team in that docs.rs and rustdoc would be involved.
- scott: other ideas are listed in https://blog.rust-lang.org/inside-rust/2024/06/19/this-development-cycle-in-cargo-1.80.html#focus-areas-without-progress.
- weihang: can a team have as many project goals as they want?
  - josh: no hard limit. Mostly just what the teams want to approve on their roadmap/radar, should be within the bandwidth of the team and the owner.
- josh: follow up on the zulip stream for more discussion.
- josh: it is not intended to be "closed" after the submissions. Things can be added afterwards. The 6-month cadence is just to kick off and get activity to get goals added. Just won't get quite the same visibility.
  - jacob: Also helps to triage the list.
- rustin: two projects, collaborating with crates.io
  - cargo yank with a message/reason. Slowed down by crates.io, they would like to have experimental feature in crates.io. That has not yet been implemented. Plan to look at this after finishing what I'm currently working on.
  - Getting cargo-util-schemas incorporated into crates.io. Was working on adding the determination if a package has a library or a binary. There are some problems with trying to make that distinction. Tried to solve that in cargo-manifest. Release model doesn't match crates.io release process. There were some concerns about using cargo-util-schemas. There seems to be some resistance.
  - josh: Good examples of cross-team coordination. A project goal could be a vehicle for driving consensus.
  - weihang: cargo-util-schemas, has alternative solution, cargo-manifest could use cargo-util-schemas. Need someone to help step up to support.
    - scott: not particularly happy with that solution as a workaround.
    - rustin: not a huge gap of requirements. Last discussion was stressful.
    - weihang: good to consider the emotional bandwidth.
      - jacob: avoidance of the problem can cause issues as well.

2024-06-18

out: epage

–compile-time-deps (for IDEs)
- In talking about bloated CLI, I feel this is too much
- Wonder if Argon could help (e.g. a command to generate a build unit graph with another command that builds a specified unit graph, allowing people to tweak it inbetween)
- scott: sees the usefulness, but recognizes the extension of the CLI could be an issue, and concerns about cache thrashing.
- arlo: Recognizes that it would be helpful, but uncertain about adding a cli option just for this. Would like to see alternatives , example: pass in specific crates to compile that could be more general.
- jacob: --partial-build=<reserved-name> to avoid polluting the namespace that is more extensible without adding more
- weihang: If there is a query system, that could also avoid polluting.
- scott: Could be nightly-only until a better solution comes up?
  - arlo: don't want to encourage RUSTC_BOOTSTRAP
- jacob: want to build some subset of deps, then stage the build cache to be reused.
- eric: a bit confused, this is just adding a flag for the last target kind that is not exposed.
- scott: uncertain about exactly what "compile-time dependency" means.
  - jacob: may not want to be too specific to allow extending in the future.
- josh: Would like to have it be unstable, and have reports from users that this is exactly what we are looking for.
- scott: Would like to reach out to other IDE to verify it would be useful.
- weihang: Does it need to run the build script?
  - proc-macros need to be executable.
- jacob: IDE support for parsing the output of build scripts would be another use case of splitting out that parsing into a library.
- weihang: query interface discussion was brought up by another rust-analyzer developer, could
- arlo: Having something that is more extensible or flexible could be helpful. Concern people will want different things over time (like just build proc-macro, or just build and not run the build-script, etc.). Concern adding something very specific for this narrow solution.
- jacob: there are solutions in some spectrum, from build exactly what they need, to some very generalized build-graph runner, could something in-between work?
- rustin: what exactly does "host-platform" mean?
  - arlo: one way to think about it is that when cross-compiling, it is the things that are built for the host.
- jacob: Would also need to decide how artifact-dependencies interact with build scripts.
- rustin: the --compile-time-deps flag seems confusing.
- josh: experimentation would be good, and if there is churn in the design that indicates it needs more work, and if it works for several users, then that indicates it is useful for them.
base paths
- josh: would like a better answer for how the base paths are defined in the normal Cargo.toml.
- arlo: This was written for a use-case where a single workspace isn't feasible, but would like to see better tie-in with workspaces.
- josh: feels like it is incomplete. Would be nice to have a workspace-relative base (the common case).
- eric: feels weird that it would be dependent on config.toml.
- josh: being exclusive to the config file, being incomplete without the config file, would be good to have a default in the manifest that you can override in the config file.
  - arlo: or define in both.
- josh:
  - base-paths (with an s)
  - should be able to write it in Cargo.toml, and override in config.toml if you want.
  - be a way to reserve names.
    - Like base="workspace".
      - Should it be allowed for the user to override those reserved names?
    - scott: could reserve cargo-* or something like that.
    - josh: not sure it needs to be a dedicated namespace. Just shadowing (like Rust name resolution), with specific rules for how conflicts are resolved.
      - That should allow adding new names in cargo (it shouldn't break the user). If the user wants to use the new special names added in cargo, they can rename their existing base.
    - arlo: could restrict characters
      - josh: agree, no path separators. Package-like identifiers.
- weihang: Is this a new Source?
  - scott: Probably want to utilize the existing PathSource.
- josh: will follow up on RFC with concerns
Allow specifying dependencies for individual artifacts
- already in FCP close

2024-06-11

FYI: analysis of diffing .crate files: https://lawngno.me/blog/2024/06/10/divine-provenance.html
announce: public/private dependencies formally removed from the edition. May introduce without edition via an opt-in.
appreciation/recognition gifts (swag, etc) for rust project, share ideas if you have.
epage: no-implicit-features and dep_name/feature_name: https://github.com/rust-lang/cargo/issues/14016
- Suggesting remove foo/feature_name, and only have ["dep:dep_name", "dep_name?/feature_name"]
- jacob: can the old syntax have the old semantics?
  - ed: concern over subtle tweak to the meaning over an edition boundary.
- https://github.com/rust-lang/cargo/issues/10556
- eric: originally was thinking of dropping ?, but walking back on that since I think it could be too confusing.
- eric: Would probably prefer to have foo/feature_name imply dep:foo.
  - In the documentation, don't emphasize it too much. Just a small note of some kind.
- ed: will work on adding the implied dep:.
root rustflags
- Add CLI-based RUSTFLAGS available to other commands like cargo test (normally only available in cargo rustc).
- jacob: how does it interact with cargo rustc?
  - Redundant
  - Josh: Maybe useful for tests and other weird cases
  - Arlo: concatenate and choose an order
  - Josh: apply this first and then cargo rustc
  - Jacob: deprecate cargo rustc?
  - Josh: no, doesn't replace
- ed: elevate to config instead of cli
  - josh: seems easier to specify on CLI. Config might need more complexity trying to specify where the flags apply.
- ed: does profile rustflags replace this?
  - weihang: mentioned in RFC
  - RFC: benefit is profile agnostic (caller can set it without knowing the profile)
  - epage: this was because they were focused on coverage, maybe not apply for regular use cases
- jacob: seems complex to specify in cargo test exactly which units it applies to. (lib versus test)
- ed: perhaps try to get profile rustflags stabilized first?
- ed: bikeshedding of the string on CLI
- jacob: postponing could be useful for pausing until other things like profile rustflags
- arlo: author may not working on RFC or Rust
  - josh: we shouldn't be adopting, but provide feedback on what we think it should look like.
- josh: there is still uncertainty about the future of profile rustflags.
- arlo: can see it can be useful, but since two years since it was written there hasn't been much activity, so uncertain about interest level.
  - ed: difficult for people to be aware of old RFCs to express interest or get it moved forward.
- jacob: the demand for rustflags seems like a process failure of the interaction of cargo and rustc.
  - josh: could the process of adding new rustc options to include the cargo team to see how it can be exposed? A rough sketch of how you would like it to be used.
- ed: an important follow-up is to figure out exactly which units it gets applied to.
  - bikeshedding the name
  - weihang: how it gets merged with other rustflags.
  - jacob: there was an internals post about the inconsistency about setting the rustflags as a string versus an array.
- ed: will follow up with postponing.
features as table, not just array
- Main issue is naming, particularly with what works well with https://github.com/rust-lang/cargo/issues/3126
  - RFC uses enables. Could be other things like activate.
  - josh: feels like enables is the obvious answer.
    - Another option to not just have one big array. Could be deps=[...], features=[..] so we aren't using string parsing to interpret. Downside is very bikesheddable which could block this.
    - ed: Benefit to keep the syntax the same is to make it easy to switch to a table.
      - Arlo: agree, would be great for being easy to convert in a text editor.
      - josh: agree.
    - jacob: a cargo-edit superpower could be used to convert from string to a table.
    - arlo: could see in the future if we add something more fancy, it could only be available in the table format.
      - josh: agree, like negative features
- required could be confusing
- josh: advocates for enables, a more common english word, easier to type
- jacob: Would be nice for any variants (like enable) would have an error message suggesting the correct form.
- ed: will do a final pass through the text, and then propose a merge
- jacob: does this RFC impact the index?
  - ed: no. The other RFCs do, but they discuss those changes.
- ed: Should Cargo.toml published version be normalized to avoid msrv? But not concerned about that. The implementation might just happen to do that, though.
- weihang: any impact on cargo_toml or cargo_manifest? Should we ping them?
  - ed: appropriate to ping the build-integration zulip channel.
- eric: would this be stabilized before the other RFCs.
  - ed: doesn't see a reason to. Benefit of early stabilization is to better support MSRV bumps.

2024-06-04

msrv edition status?
- https://github.com/rust-lang/cargo/issues/9930
- epage: https://github.com/rust-lang/cargo/issues/13540
- only edition-related thing is the "resolver" section, and only thing left is config.
- config could possibly have generic fields versus being more specific (independent control of settings). Might be easier to move forward with a single field.
- weihang: could possibly make resolver extendable with plugins, which might make it easier to do some iteration on various options.
  - ed: cargo-semver-checks is an example where they always want to have a resolve including yanked.
- josh: instinct to stabilize the simplest design. rust-version seems more orthogonal than the other examples. Make it a toggle (compatible/incompatible). Other options could come later.
  - likes resolver.rust-version
- arlo: One thing that could help is to avoid true/false values, and have enumerations instead.
- josh: skeptical that yanked would be a global option to enable.
  - ed: There is a use-case for cargo-semver-checks, where if there are two things are yanked (indirect), you can't use --precise to override that.
  - josh: debian has a stable/experimental, which allows an experimental dependency to pull in other experimental dependencies.
- What is "discourage"?
  - The resolver does not reject incompatible packages, it just deprioritizes them. If there is no other compatible version found, it will pick the incompatible one.
  - Jacob: In some way an implementation detail that has leaked out.
- Ed: That's why just doing a single policy (or "precedence") field could punt on all the mess, and just provide specific policies.
- josh: precedence=maximum|rust-version seems like it is combining two things that are not in the same category.
  - Ed: That's correct. This is intended to be more like a profile, where it is an overall policy. Intended as a short-term solution, until we get clarity on all the different separate fields.
  - josh: to clarify, is that to avoid dealing with all the combinations of all the different options?
- ed: Also consider this can be stabilized before the edition, and then change the default in the edition.
- josh: likes to avoid picking words that might be difficult for non-native speakers, but "disprefer" is an option.
- jacob: Talk to an LLM :D
- difficulty of naming "discourage"
  - arlo: liked avoid
  - josh: we are trying to find a word that is not absolute.
  - josh: "last-resort"
    - ed: If we add other things like "yanked", then what is the priority (last-last-resort).
    - incompatible-rust-version = "fallback"
    - allow/fallback
    - arlo: considering noun vs verb
      - josh: Could do "allowed", but seems needlessly different.
- ed: Will try to mull over this, collect some thoughts and feedback.
Access to compiler artifact notifications messages
- eric: can speculate a little, where it is exposing very low-level raw details
  - rlib
- eric: exposes internal directories people shouldn't be digging into
- josh: --json emitted-artifacts in rustc could limit which artifacts are emitted
  - There's no way to differentiate the different emitted artifacts, cargo still needs to pass its own --emit.
  - There's also still the issue of pointing into deps, and not "uplifting" to the output directory.
- cargo-show-asm is using cargo metadata, it does not link to cargo.
- weihang: Is it possible to use RUSTC_WRAPPER to highjack and capture the artifact notification?
- eric: Only idea I had in the past was to add --emit to cargo rustc, so that cargo knows what you are trying to accomplish and can provide all the information (JSON, uplifting the output, etc.).
- josh: If using cargo rustc, you are already reaching for a direct usage of rustc, so accessing raw details like --emit should be fine.
- arlo: Could cargo's JSON output wrap rustc's raw JSON information, and make it clearer this is raw information.
- josh: thought experiment: how would we do this if cargo-show-asm were a built-in command? how would that be implemented?
- ed: Will summarize some of what we talked about here on the issue, and try to figure out options from there.

2024-05-28

weihang: allow panic = "abort" in custom harness
- https://github.com/rust-lang/cargo/issues/11214
- benefit
  - performance and binary size concern
  - align with actual release build with panic=abort
  - work with #[cfg(panic = "unwind")]
- The setting is on the profile which is across all targets and we intentionally ignore it in tests to avoid bins being aborted to affect tests
- eric: one concern is around backwards compatibility
  - cargo will transparently switch to unwind, and if a custom harness is expecting that behavior, it will no longer work correctly if built with abort.
  - one idea is to require profile.test.panic = "unwind" if that is the behavior you want.
- ed: one thing would be able to set target settings across all targets of a type (all tests, for example)
- eric: is this for both test/bench, or just bench?
  - weihang: the user request is for bench. but being the same could also be beneficial
- eric: will work with weihang to come to a more concrete proposal.
Josh:
```
build.rs = '''
fn main() {
    ...
}
'''
# or
build.rs.output = '''
cargo::directive=...
'''
```
- epage: completely static build.rs seems pretty rare
- epage: embedding source seems annoying to develop and doesn't buy us much (personally, I'm fine with build.rs being out of scope for cargo-script)
- josh: use case is if someone has a cargo project, and wants to collect it into a single script file for a bug report or other self-contained thing, it would be helpful to allow build script.
- jacob: seems like a reasonable feature, but perhaps wait until stabilized till adding other extensions
- jacob: a partial anti-goal of having multiple files.
- epage: If we reconsider this then we should reconsider the possibility of "rolling up" a non-script into a script.
- epage: Way to delegate build scripts to dependencies.
  - eric: you can do that today with "metabuild", but uncertain if it will ever get stabilized, nobody has been using it.
  - https://crates.io/crates/system-deps is an example. and https://github.com/joshtriplett/metadeps
  - That could help with this use case.
  - josh: only handles -sys, not reproduction
    - epage: work to replace build.rs
- arlo: If there aren't multiple files, specializing build scripts seems strange.
  - Would prefer to push people to make crates (like -sys) for those needs.
- josh: originally proposed since this didn't seem like a substantial extension. Wouldn't want general purpose multiple files.
- epage: Would require handling in rustc.
  - josh: Good point, should probably defer this until after file and line directives exist
- Jacob: defer until after script is stable
  - josh: also until after file/line directives are stable
weihang: Path to stabilizing --precise <yanked|pre-release>
- Call for testing.
- Wonder if we'd like to push pre-release matching logic to semver
- No feedback received.
- https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#precise-pre-release
- https://github.com/rust-lang/cargo/issues/4225
- pedrag mentioned it doesn't support multiple yanked packages.
- Lose backtracking for pre-release or yanked.
- weihang: support for that could be added as as separate issue.
- Does <3.0 match 3.0-alpha? This could be a weird expectation.
- Yanked doesn't have the operator problem.
- epage/arlo: call for testing probably won't be an issue.
- is adding to the semver crate a blocker for stabilizations for pre-release?
  - Getting it solidified with semver maintainer, could help get feedback.
- https://rust-lang.github.io/rfcs/3493-precise-pre-release-cargo-update.html
- eric: doesn't expect an issue with updating semver, since the stated goal is to support whatever cargo wants.
  - epage: would be helpful to get feedback
- josh: would be good to survey crates.io and determine the unique suffixes that are used (metadata and pre-release), and categorize them, and determine what circumstances people use pre-release instead of metadata (where there is an incorrect semantic meaning).
- josh: probably not a big deal since it is an opt-in via update --precise.
- arlo: what would happen if someone manually updated Cargo.lock?
- josh: unlikely to cause problems with update --precise, but there are possibly inconsistent semantics with operators. <2 versus ^2, would like to have those to have semantics and behavior that make sense so that pre-releases are not both < and >.
- jacob: Would like someone to write a table, explain the mental model, and show there is some consistency with how things work.
- conclusion:
  - seems good to stablize "yanked".
  - Needs someone to write a stabilization report for pre-release, explaining how the mental model works and show the consistency (or well-documented inconsistency).
recommended-bin-packages
- epage: seems like a diagnostic namespace kind of thing.
- Is there not enough interest now, and defer? Or is there a way to move it forward?
- epage: can get a little complicated/weird, since a package refers to its dependents. Other issues like version relationship. Various corner cases.
  - Also just bikeshedding how it is specified.
  - Could be more general, here's an error string if there is no bin target.
- weihang: this was possibly raised due to lack of nested package support.
- epage: This specifically helps with the separate bin/lib workflow.
- epage: would it make sense to have a diagnostic table? Would there be other ideas of things that would go there?
- josh: Does it makes sense in the lints namespace?
  - Doesn't really match, since lints are about controlling the lints.
- Ideas for a diagnostic table:
  - MSRV fail
  - platform/target limitations
  - ~~build scripts?~~ too weird
  - diagnostics.install-lib = {packages=[...]}
- What lessons can we learn from diagnostic namespace?
- conclusion: epage will write up, and waiting on author for follow-up.
  - josh: could start FCP with a concern to change it.

2024-05-21

check-cfg
- https://github.com/rust-lang/cargo/pull/13925
  - Silence the warning lints config warning on Beta?
  - This was added in 1.80 (nightly)
  - Backport to beta means 1.79 won't warn, giving one release window without a warning.
  - no objections to beta change
- https://github.com/rust-lang/cargo/pull/13913#issuecomment-2121519232
  - Inconsistent -
  - We only check for unexpected_cfgs, not unexpected-cfgs
  - In 2024-04-30, we decided to use underscores for cargo lint names. Ed wonders if we should walk back that decision?
  - josh: This inconsistency doesn't seem all that important. Individual decisions made sense, but the overall result kind sucks, but so be it.
  - scott: Supporting both _ and - is an option, which might help people if using from (a future) command-line.
  - If you specify lints.rust.unexpected-cfgs.check-cfg, this gives an unused manifest key warning.
  - eric: Since this is lints.rust, would it be ok to support both to be consistent with rustc?
    - should we push to a canonical representation?
    - What happens if both are set? That isn't prevented.
  - ed: leans toward supporting one or the other.
  - josh: meh
  - weihang: Do we also need to consider ' versus " for shipping this feature?
  - The _ and - issue is also an issue for feature names and dependencies, where it is externally defined.
  - ed: How about doing an edition change to only have underscores in the [lints] table?
    - eric: leans towards deferring that decision
    - We can always have other ways of transitioning, such as warnings.
  - no specific changes proposed at this time
- https://github.com/rust-lang/cargo/pull/13934#discussion_r1606791777
  - Optional level. Should we require something or not?
  - This is an MSRV bump.
  - ed: Doesn't feel there is a rush to resolve this.
  - This change allows you to set check-cfg without the level. The level="warn" is restating the default, so doesn't seem necessary.
  - scott: Thinks it is good to pin the level, so it is stable even if the default changes.
  - weihang: agrees with scott. Better to be explicit, at least for now, and can revisit this later.
  - jacob: keep in mind which way is a one-way door. If we later decide the implied route was a mistake, that is the harder thing to change later.
  - decision: defer this till later
epage: clarifying our stance on stale open RFCs?
- For one person, a source of stress for the 2024 Edition was that the RFC author and the approving team each thought they were waiting on the other.
  - https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/should.20have.20been.202025.20edition/near/435856044
- We should probably give clearer dispositions and closing, even if we like the idea, might be justified.
- Josh: Clarifying: we're solely talking about open, not-yet-accepted RFCs?
- ed: Would prefer to be more proactive to make it clearer where things are going.
- josh: If something is marked waiting on author, could a bot ping it after 3 months?
  - eric: people tend to hate stalebots
  - josh: Specifically, when the author hasn't done anything.
- ed: Can do a pass to label waiting-on-author, and ping authors.
- eric: https://github.com/orgs/rust-lang/projects/47/views/3 shows last activity for author, cargo team, etc.
- josh: Can we use agenda generator bot? This would help to bubble things up such as older rfcs.
- eric: Some problems in the past:
  - It is a time commitment to read and understand the RFC (either before the meeting, or during).
  - Some RFCs require a lot of discussion or mired in decisions that take a large time commitment.
- ed: Can be rough to close something, especially if someone put a lot of time on it, but might be better than being ignored.
- ed: Will do another pass to figure out the status.
Josh: Allowing everything fom [package] at top-level? This would be convenient for cargo-script, to allow writing just edtion = "2024" rather than package.edition = "2024".
- Primary difficulty: detecting workspaces that have a top-level package would require looking for the individual fields.
- epage: #[serde(flatten)] causes annoyances with things like unused manifest keys, maybe error messages
- scott: can we allow it only for cargo-script?
- jacob: Could allow this except for workspace/package hybrid Cargo.tomls.
- ed: would prefer to keep it consistent with cargo-script.
- josh: cargo-script is the original motivation, but would be nice for other users. Wouldn't have proposed this for just regular manifests.
- jacob: Would it be possible to defer this decision until after cargo-script is stabilized.
- The main objection here is implementation complexity, not the semantic of the change itself.
  - It seems there would be much less concern if the implementation was simple.
- rustin: If only cargo-script, and you want to convert script to a real project, that could make it a little awkward to copy that to Cargo.toml.
  - Yea, that is a reason that having consistency would be beneficial.
epage: Templated CARGO_TARGET_DIR RFC: https://github.com/rust-lang/rfcs/pull/3371#issuecomment-1602959262
- Please take a look and raise concerns or check boxes for FCP.
- jacob: slippery slope of adding templating to configuration. That can set precedent for people wanting templating in other places. envs for example.

2024-05-14

epage: --check-cfg
- We were against [cfg], but what about
```
[lints.rust]
unexpected_cfg = "allow"
unexpected_cfg = { level = "allow", check-cfg = ["cfg(any)"] }
unexpected_cfg = { check-cfg = ["cfg(any)"] }
```
- Off in the corner rather than top-level table
- Low level mechanism rather than (lint name and its flag) rather than half-way high level abstraction
- Has the appearance of being associated with rustc
- T-compiler is good with us managing their config and curious about leveraging this in other ways
- Proof of concept: https://github.com/rust-lang/cargo/compare/master...Urgau:cargo:check-cfg-lints-sub-config
- (also improving docs and error messages)
- scott: This is the first time supporting lint configuration. Feels odd to control rust's output from within cargo. But doesn't feel like there is no other place to put it. A new precedent.
- josh: no strong feeling where it should go, don't worry too much about bikeshed, either have a static mechanism in Cargo.toml, or people should be using private features and find a path to stabilize this.
  - josh: Nice to ship a non-build.rs solution timely.
- jacob: there is also a temporary mitigation to stabilize at allow-by-default.
  - ed: had a concern about rustc ignoring by default cfg settings specified on the command-line, maybe cargo could -Aunexpected-cfg.
- arlo: what about rustflags?
  - Don't really want that to be the solution.
- arlo: How are these cfgs usually set?
  - Via build.rs
  - User set it via RUSTFLAGS
  - fuzzing/connie/loom — the tool sets on their behalf (via some rustflags method).
  - The problem here is that the check-cfg needs to be set even when not setting the flag or running a tool.
- scott: can delay stabilization for one cycle.
- eric: Would these configs also be extendable for clippy?
  - ed: They want to continue using their own config file. Also, configs aren't necessarily per-lint.
- arlo: Would this be custom logic per lint.
  - ed: yes
- scott: Clippy could have a key in the lints table dedicated for config.
- arlo: also update the rustc error message to tell the user about the [lints] config.
- eric: just checking on the backwards compatibility. It works if there is a level="warn" in the sub-table, but that appears to be required.
- ed: how to balance responding to people concerned about a change. Concern about over-endorse people using nightly.
  - Could switch to allow just before beta branch if we need more time.
- rustin: Question about the syntax: why does it need a sub-table?
  - unexpected_cfg is the lint name, and it needs to be able to set the level as a string, so it can't be something else.
- arlo: do we want the level to be optional?
  - that's something we'll need to figure out.
  - ed: How does merging work if we ever support packages overriding workspaces?
- arlo: How long will it take to add lints table support?
  - Would prefer to not put pressure on Urgau to get it done.
  - Earliest a couple weeks, possibly next release?
  - Try to make a decision ~ may 31.
- conclusion: will add support to the lints table.
eric: Adding crater-specific code to support cargo fix --edition?
- Due to the way crater works, it isn't really feasible to have it drive the migration, and cargo is really the only place it can live. Are we ok with adding a hidden option for that?
- scott: could add it temporarily, and then rip it out.
- jacob: precedent we have -Zno-index-update just for crater.
- ed: is it possible to copy a script into the image?
- What is the image they are using?
  - eric: I think they are using some generic linux and windows images.
- weihang: recall ed proposed able to automate the edition fix workflow?
  - eric: if that happens, we can update crater to do what needs to be done.
epage: where should lints and diagnostics live?
- Where in cargo's code do they get processed?
- Before: during parse, we'd (1) error immediately, (2) error eventually for workspace members, (3) warn eventually for workspace members
- Now, we do it during parse and now some lints when ready to emit (for workspace members)
- Some of that processing is slow
- Also be simpler to do with rest of lints
- What
  - From unused key warnings to maybe even Edition-change errors
- emit_warnings only called for compilation commands and cargo fetch
  - cargo publish will do this for the published-manifest unless --no-verify is used
  - Maybe add cargo verify-project
  - A case could be made for cargo metadata but if/when we do json output for diagnostics things would be confusing to parse
  - cargo tree?
  - cargo vendor as it could affect vendoring?
- scott: have been thinking about doing something similar to rustc where there are different passes at different stages (early, late, etc.). That could help here.
- ed: The important question here is which commands will emit warnings/errors (like cargo metadata).
- eric: doesn't care about cargo metadata since that isn't human consumable right now. cargo publish --no-verify is one of the stranger ones, but I guess that since you are saying "no verify", then it is ok not to tell the user.
- arlo: This is just warnings, not errors?
  - ed: The edition deprecations like the [project] table.
  - arlo: Just a concern if there are errors that would start passing.
- ed: is fine with moving most of the things (primarily for performance), and is ok if not everything is moved.
- scott: would it be helpful to show a table showing the changes for specific lints?
- ed: concerns about compatibility? Is that a breaking change?
  - arlo: If it is a warning, not a problem.
  - ed: Can also be deny.
  - What about rust-analyzer using cargo metadata? What that would see would probably be too minor.
- Conclusion: OK to move things to a later stage.

2024-05-07

out: epage, josh

2024 Foundation fellowship mentors: https://docs.google.com/document/d/1K40eZC-faYPSIhEvRa0cNhNP-2JugvkKC7fKlqWG0l0/edit#heading=h.kcr7zl8yp6kc
- Also related https://github.com/rust-lang/rust-project-goals
Notice about travel expenses (check all@ email).
cfg checking
- ~17% regression on syn
- Some users don't want to use a build script since it seems heavy-handed.
- jacob: Could rustc have a lint configuration (like how clippy does)
- eric: Some context: There was a declarative syntax in Cargo.toml, but we decided not to support that since it created a parallel system to cargo features, and we didn't want to create that, and instead extend cargo features to support the use cases (global features, private features, etc.)
```
warning: unexpected `cfg` condition name: `foo`
 --> src/main.rs:2:13
  |
2 |     if cfg!(foo) {}
  |             ^^^
  |
  = help: expected names are: `clippy`, `debug_assertions`, `doc`, `docsrs`, `doctest`, `feature`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `rustfmt`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `ub_checks`, `unix`, `windows`
  = help: consider using a Cargo feature instead or adding `println!("cargo::rustc-check-cfg=cfg(foo)");` to the top of the `build.rs`
  = note: see <https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default
```
- The help message could possibly say more explicitly to allow(unexpected_cfgs)
- eric: The blog could have been a little clearer about it being disabled. From a user's perspective, the difference between allow and disabled isn't different.
- arlo: The link to the docs is about build scripts.
- eric: The concerns about the documentation was brought up during review, but there wasn't a clear place where to have that documentation. We didn't want to duplicate everything between rustc and cargo. But we didn't want to include all the cargo docs in rustc.
- Some resistance to having project-specific exceptions in rustc.
- jacob: What is a long-term solution for something like fuzzing?
  - eric: One option is to have private features?
  - jacob: When being used as a dependency, there are code paths that need to be changed.
  - That could also be a global feature, like an intersection of both global and private.
  - arlo: Though it seems like it isn't really "private" if that is a way the package compiles differently.
  - Jacob: fuzzing isn't clear if you do or don't want your dependencies to behave differently when fuzzing is enabled.
- What to do in the short term?
  - Back to unstable?
  - Make it allow-by-default?
  - ~4 weeks to make a decision
  - weihang: When it hits stable, it could get a larger response.
  - epage: see https://github.com/rust-lang/rust/issues/124800#issuecomment-2098488983
  - arlo: feels strongly we can't do nothing.
    - preferred option is to be able to list it in a config file or manifest file
  - eric: mostly in the hands of urgau and ed, let's have followup on 124800 if anyone has strong opinions about what to do.
- Follow up from Office Hour: https://github.com/rust-lang/rust/issues/124800#issuecomment-2100964458
weihang: https://github.com/rust-lang/cargo/issues/13720
- Emscripten has an additional file that needs to be uplifted. *.worker.js
- Question about tier2/3 support. Should cargo know about everything those targets need?
- arlo: What is making this file?
  - A linker flag: -C link-args=-pthread
- eric: preference was to have rustc tell cargo what files should be copied, just never got around to designing that
- eric: Don't have a clear answer for tier2/3 support. Generally in the past have accepted some PRs, but don't go out of our way to support it.
- eric: leans towards being ok to add .worker.js to the list of special files (we already have .wasm.map).
- weihang: will follow up on the issue.

2024-04-30

out: jacob, rustin

scott: Should we strip [lints] on package/publish?
- Brought up by epage in #13806, which is about stripping [lints.cargo] on publish to avoid accidential MSRV bumps
- One solution would be to strip the table if the MSRV older than [lints] stabilization
- Main question is interaction with cap-lints, can the table affect dependents build
- The lints table itself wasn't an error (thus not an MSRV requirement), but random tools (sub-tables) are an error, and lints.cargo generates an error.
- josh: An option is to just make lints.cargo require an msrv bump.
- arlo: Did we intentionally consider the sub-tables being an error wrt MSRV impact?
  - ed: Not exactly.
  - Could be an unused tools warning.
- arlo: Is there precedent for stripping stuff?
  - scott: Workspace-inheritance is an example. Also a non-virtual workspace strips the entire [workspace].
  - arlo: That isn't a loss of information, but lints would be a loss.
- rustc cap-lints "allow" forces all lints to "allow".
  - The only way to observe this if you are building the crate from the .crate file manually.
- ed: ok with changing from error (for all tools) to a warning so this isn't a problem in the future.
- josh: do we expect this for other tools in the future?
  - ed: cargo-semver-checks (and some other tools like redpen) might have their own namespaces.
- ed: If there is a warning, don't want to make it possible to "allow" it.
- josh: The warning should spell out explicitly that there are no compatibility guarantees (that it may be used in the future?).
- weihang: Could have a statement that everything is reserved except for the open tables like package.metadata.
- conclusion: change tool sub-tables to be a warning. The warning should not show up in registry dependencies.
- weihang: Should the warning change be in beta?
  - Probably not necessary, lints.cargo is already a warning, this would only affect other tools.
scott: Should we allow lints to be specifed with both - and _ in [lints.cargo]?
- In #13635, I made all currently implmented lints use _ internally, but allowed - and _ to be used in [lints.cargo]
  - I made this change to match the rustc-dev-guide, and RFC #0344, though it appears both are referring to attribute macros, not rustc's CLI
  - rustc's CLI seems to prefer -, as -D unused_imports gets rewritten to -D unused-imports when used in note: requested on the command line with messages
  - rustc rewrites - to _ internally when specified on the command line
- Thought of this because of dev_dependencies vs dependencies
- Problems with having - and _:
  - We have to check both if we are trying get the span of a lint name
  - Documentation must show the name with - and _ (see the rustc lints section)
- Personally lean towards only - and emitting a warning with a suggestion when _ is encountered
- Should lints.cargo support underscores and dashes? Or just dashes? Or just underscores?
- scott: Leaning towards dashes.
- ed: Likes just underscores, since that feels like the canonical form.
- arlo: No particular opinion, but thinks we should decide now and pick just one form.
- ed: And can always support the other form in the future.
- josh: Does not expect the style team would mandate a style here. If both were accepted, then probably the style would say "don't change it when formatting".
- weihang: Are we going to type lint names on the command-line?
  - ed: No plan for now (for lints.cargo).
  - weihang: Benefit for dash is easier to type. Underscore is nicer for searching for identifiers.
- rustc is somewhat inconsistent. The dashes show up when referring to command-line, underscores when coming from attributes.
- scott: Still personally likes dashes aesthetically.
- decision: Use underscores for now.
- unused lints will be displayed for dashes
  - ed: And could maybe have a "did you mean" type of note when using dashes.
epage: bit-set 0.2 / libusb breakage (https://github.com/rust-lang/cargo/issues/13824)
- We removed support for dependencies without a source a few weeks ago after a 2.5 year delay.
  - dependencies.bit-vec = {}
  - Cargo previously treated this as bit-vec = "*"
  - A few weeks ago, we changed this to an error.
- bit-set 0.3 are fixed, but 0.2 is broken. People have been having trouble getting libusb updated to newer bit-set.
- ed: Could add a specific hack for bit-set to be allowed.
- ed: Could add a rustsec "unmaintained" status for libusb.
- Josh: Is there maintained fork of libusb?
  - Not that we've know about?
  - There does appear to be a few alternatives, like https://crates.io/crates/libusb-src and https://crates.io/crates/libusb1-sys, and these appear to be popular.
- scott: Could be a future-incompat report, and delay the error for a while.
  - Or make it 2024 edition change.
- weihang: Talk to rustsec about "unmaintained"?
- josh: Feels ok with just breaking it. Although it is a compatibility issue, it was an unintended bug.
- decision: Stay with the current error.
  - ed: Will look into a rustsec unmaintained notice.
eric: artifact-dependencies reviews
- Are people ok with doing reviews on it? It is a pretty high time cost since we get so few PRs, we are all out of context.
- josh: Happy to help with design decisions, but may not be able to help as much with code reviews.
- eric: Will follow up on the issue which I think should be relatively simple, but we will likely need to talk more about some of the more complex PRs that take a large time investment.
- weihang: Enterprise may want to invest in this area, may have other design considerations for them.
arlo: SBOM RFC open issues
- What config key should enable SBOM generation?
  - CARGO_BUILD_SBOM vs using a profile
- Are we ok with deferring including additional information?
- josh: Reasoning for a profile: It makes sense for a certain type of build ("deploy"), but not necessarily wanted in a different environment.
  - josh: If the information is in a separate file, then it doesn't matter too much. It mostly just matters if it is embedded in a file.
  - arlo: This RFC is focused on making the information available, not embedded.
  - ed: Two angles: One is something similar to split debuginfo (a file that just exists alongside the output), the other angle is getting unit-graph-like functionality where a build orchestrator can collect that information. For the build tools, then it makes sense to be controlled as a configuration option.
  - arlo: My perspective is that this is mainly oriented for tools, and not like debug.
  - josh: A global environment variable seems reasonable. Sees two use cases, I wrote the binary crate and I set it in Cargo.toml, the other is someone building software as a distribution and I want to set it for everything (like config.toml/env var).
- ed: Could do both in the future if we decide one way now.
- arlo: If this was embedded, then it would make more sense for the profile.
- Ran out of time, will continue discussion separately.

2024-04-23

epage: Edition 2024 updates
- one deprecation in, two more left. _ deprecation still some small work left.
- msrv resolver, one bug away from being code complete
- yeeted config field and values, still to be bikesheded, will likely call for testing before settling on a name
- scott: Finalizing implicit features
epage: OSPP (Chinese GSoC) proposals are due at the end of this week
- Time table runs 2 months later than GSoC
epage: easy opt-in for release profile for cargo-script
- lang change has been approved
- https://github.com/rust-lang/rfcs/pull/3502#discussion_r1337996703
- Can't have dev inherit release
  - Maybe offer cargo::dev and cargo::release and allow dev to do whatever it wants
- If we could introduce a run profile
  - By name, should transition cargo run to it
  - Would need to be done in a compatible way
- Could have --release in #! header on platforms where that is supported
- Current profile is dev
- josh: bad idea but might inspire good ideas: Could run in debug when you run, and in the background compile in release mode so the next time it runs in release mode. Among other reasons that's a bad idea: that'd be non-deterministic.
- arlo: Is there a way to specify config options?
  - ed: no. One improvement is to continue pushing config options into Cargo.toml. There is some intentional limitations in what a script can do (ie build-scripts, multiple file, etc.)
  - josh: doesn't think the person installing this will know best of what settings to use, the person who wrote the script likely knows the performance requirements. Some way to specifying the default profile inside the script seems like a good option (e.g. default-profile = "release". In the manifest format. Take the opportunity for config options to go in the manifest.
  - ed: config loads relative to the script (similar to cargo install) not where it is run. In that case, the script author might be able to control that.
  - josh: should probably not load config for security reasons. Scripts often get run from a temporary directory or downloads directory. (home directory is fine)
  - ed: Could reparent the script to pick up the config from the user's home directory (~/.cargo/config.toml).
  - ed: not loading config from where the script is limits the script author's ability to specify options
  - josh: Could use config from a workspace once we have scripts as part of a workspace.
  - ed: would need to determine if it is safe to reload the config after the workspace has been loaded (cargo install reloads before). There are some config options, like profiles, that are loaded early during workspace loading.
  - ed: Should we consider deferring this decision later if we have an idea for adding it later in a compatible way?
    - josh: Acknowledge in the RFC this deferral, document how to change the "dev" profile, mention in future work that we might add a default-profile option or similar.
epage: precedence of cargo <foo>
- https://github.com/rust-lang/rfcs/pull/3502#discussion_r1337912575
- https://github.com/epage/cargo-script-mvs/issues/154
- Scripts named test can't be invoked as cargo test, only cargo ./test
  - josh: We could issue a warning, but that'd require us to look closely enough at the script we're ignoring to tell that it's a script.
  - josh: This is also an argument for having a separate cargo-script binary
  - josh: However, running a program without a path and without ./, which requires it to be on the path (possibly by having the working directory in the path), seems sufficiently uncommon that this doesn't seem critical to fix. And if you put a script into a directory on the path, you probably give it a reasonable name.
- scott: Could be similar to alias override precedence?
  - ed: A very likely scenario is test which won't work.
- josh: seems unlikely that the script will be in PATH, and named something like test.
- josh: feels like this is probably not something we should be worried about
  - Could consider warning where there is a potential conflict, but probably not worth doing
- arlo: Should we consider the namespace collisions? Although this is essentially the same problem as subcommand collisions.
- josh: Wondering about startup information on linux that tells you that you are running as an interpreter. Is that maybe something cargo could check?
  - josh: Follow-up from after the meeting: it's AT_EXECFN.

2024-04-16

epage: unused optional dependencies and the Index / Resolver, see https://github.com/rust-lang/cargo/issues/12826#issuecomment-2057870468
- Would we want unused optional dependencies to affect the resolve and being Cargo.lock or should they be ignored?
  - If you make a dependency unused and then make it used again, it would get removed from the lockfile and re-added, losing what version was locked to (but could be restored through git if it mattered)
  - josh: Some packages have unused optional dependencies that are intentionally not used to influence resolution.
    - They didn't care about the feature, they just want to affect resolution.
    - This is a binary package (otherwise, it would be completely ignored by the resolver).
    - ed: Also have seen [target.'cfg()'] that evaluates to never.
  - Jacob: Could bump the v field in the index.
  - josh: Could we stuff the entire manifest in the index?
    - jacob: Need to be a little careful with exponential growth. Though it would only accelerate the problem as a constant factor.
  - Nobody can think of a strong reason to include unused optional dependencies in resolution.
  - scott: If they get a warning, and they fix that, it will change the version in Cargo.lock, possibly different from what they had before.
    - Could happen if updating edition without using cargo fix --edition.
- Long term, do we want the Edition in the Index regardless?
  - Josh: Should we systematically ensure that the entire Cargo.toml manifest is in the index? Some feedback from infra suggests that the size of the index files does not seem to be a concern.
- Long term, are we ok with no linting of optional dependencies?
- conclusion: Strip unused optional dependencies before generating a Summary / before publish
epage: final input on deprecations, particularly for Edition 2024?
- https://hackmd.io/@rust-cargo-team/BySdIpSe0
- Could make errors in an edition as a test-bed, and then transition to all editions later.
- Process
  - Async is hard
  - Some is tied to 2024 edition which is timely
- dependency without path, version, git, workspace specified
  - jacob: This is wildly wrong behavior.
  - conclusion: hard error all editions
- license-file and readme pointing to a non-existent file
  - Some people used an empty string to indicate they don't have that.
  - license does not have false, but that's because readme has auto-discovery.
  - ~~edition ban on empty string~~
  - hard error for everything
  - eric: How many packages would be affected by the empty string? I only see one package in crates.io that has done that.
  - https://github.com/rust-lang/cargo/pull/12036 – Added consistency for handling empty string the same as missing.
- dev_dependencies/build_dependencies/default_features/crate_types/proc_macro
  - arlo: Could warn on older editions.
  - conclusion: error in 2024, consider a warning for older versions?
- good old [project] (replaced with [package])
  - conclusion: error in 2024
- default-features in inherited dependencies
  - conclusion: error in 2024
- plugin support
  - scott: could make this a lint that could be denied
  - josh: maybe consider this as an error instead of a warning?
  - scott: could be nice to reclaim the name for the future.
  - eric: just had a vague feeling that some packages set it to switch to a dylib, but doesn't feel strongly enough to influence the decision.
  - conclusion: make it an unused warning
- –release is ignored when paired with –profile
  - conclusion: make it an error
- cargo read-manifest
  - https://github.com/rust-lang/cargo/pull/3150
    - No reason given for why it was deprecated.
  - eric: What are the alternatives for a user to get similar manifest information?
    - cargo-util-schema could parse toml, but doesn't necessarily get inferred targets and such
    - could parse toml from cargo package
    - ~600 hits in cs.github.com. Mostly scripts getting name, version, description, etc. That's a little more difficult with cargo metadata, may need to do some jq magic.
  - eric: propose punt on this in the meeting, and investigate some more on what people use it for and what we might think it could be replaced with
eh2406: Asynchronous Thoughts on https://hackmd.io/@eh2406/ryRCpdoCa? Specifically any objections?

2024-04-09

epage: re-visiting the "vendoring dependencies into src/" from nested packages
- wg-secure-code views people using this practice to resolve dependencies being unmaintained as a good and people doing it is a sign of success for their process
- Is this a nuanced enough situation that in the subtltly of our stance, its ok or should we more formally reach out?
- See https://rust-lang.zulipchat.com/#narrow/stream/146229-wg-secure-code/topic/Backfiring.20of.20unmaintained.20status/near/429656875
- Example: yaml-rust went unmaintained. Someone vendored it to stop getting user reports, but there were otherwise no issues with it.
  - Someone mentioned this happens in npm ecosystem.
- ed: Would prefer to not have the cargo ecosystem go in this direction.
- Should there be discussions with wg-secure-code on expectations of community norms.
- arlo: The ideal situation is the unmaintained status points to the replacement, but not much can be done if no replacement. Doesn't like copying, since that hides the problem.
- josh: In practice, copying into your source tree doesn't mean taking responsibility for maintaining it.
- ed: Bad actors might look for packages that are not maintained.
  - CVE's won't be seen for things that have been vendored. Bad actor could target those that have been vendored without being fixed.
- "Black Duck"
- Josh: Flagging unmaintined software would be better off if everyone did it, but uncertain about the process of having wg unilateraly marking unmaintained.
- ed: Raising unmaintained as a security issue raises the temperature beyond what is needed? for a security report.
- arlo: Would be good to have a mechanism to identify when the community has moved on to a replacement. Similar to identifying major version changes.
- ed: Thinking about having something broader than rustsec, which could track not only security vulnerabilities, but separate categories of other things (like unmaintained), which would have a different UX compared to secure wg.
- jacob: reality versus ux question, both matter. If db had a section that is information or things like "maintanance", it would have an ID number which could run into the same problem of it being a "scary" number.
- ed: This could be reported in a fashion similar to future-incompat where it cargo could just tell you the status. Or the identifiers could be distinct so the difference from security is clear.
- josh: Unmaintained is being treated as a CVE, which prevents people from treating it differently from a security issue.
- ed: cargo deny is changing the "unmaintained" status from a warning to an error. The database is agnostic to the severity of the warning. Unfortunately it is getting presented all as the same level.
- weihang: CVE scoring system has criteria, does unmaintained have any sort of scoring process for determining it is unmaintained?
  - There is a process described here: https://github.com/rustsec/advisory-db/blob/main/HOWTO_UNMAINTAINED.md
- There is a disconnect between the cargo team saying you shouldn't vendor into your package, and the wg saying it is a good thing when people do that.
- weihang: They maybe said it was good because there was no other option. Is it possible to have a better tool to mitigate this situation?
  - One example would be a patch dependency. ed: That probably doesn't provide an avenue for fixing this. The issue is the risk of the problem in something unmaintained?
- jacob: Uncertain on how to align. Chatting on Zulip probably isn't going to make progress. Perhaps our disagreement isn't that big.
  - The pressure to have a new maintainer could have a similar issue like xz.
    - But also don't want to discourage new maintainers.
- ed: What should someone do if they get pressure if they have an unmaintained dependency. It can cause stress, even if there isn't an immediate issue. Vendoring is the quick solution to silence that. There aren't really good alternatives.
- eric: What would be a good alternative if you got a notice about an unmaintained dependency?
  - ed: An example of a dev-dependency, it was mostly just stressful and churn that didn't help the overall security.
  - Could be a pedantic-level lint. Shouldn't be an error that requires immediate attention.
- cargo-deny (embark), cargo-audit (official), and cargo-audit github action. cargo-audit classifies as a warning. cargo-deny is more flexible of warnings versus errors. GitHub action generates issues.
  - cargo-deny treats unmaintained as an error. Still discussion going on about that.
- jacob: Would prefer to not hear about unmaintained unless there is a real security advisory, or a replacement has been determined.
  - ed: There aren't official replacements. That implies some endorsement. But you really need to vet a replacement like it is a new dependency.
- arlo: Is this an issue with rustsec, or is it how the tools are presenting it?
  - ed: It is a fundamental framing problem, where the security database is surfacing it, and thus it is interpreted as a security issue.
  - arlo: Are there other non-security issues in the db?
    - ed: There are soundness issues.
- jacob: There is a certain amount of normalcy of security databases having a bunch of noisy notices.
- ed: Is the general feeling that the cargo team feels like nested packages should not encourage vendoring, but not necessarily making a broader statement that vendoring in general shouldn't be done?
  - ed: I feel it is very bad to be surfacing unmaintained in this way.
  - josh: Voicing your individual opinion seems like a viable option.
- eric: Still interested in the broader discussion of having a system for communicating to users about the "status?" of packages, for example things that would tie in with "cargo yank" reasons. Where "security" would just be one piece of that.
- Jacob: Wondering if there is a way to have cross-team meetings, to have better communication.
- Wondering about the role of rustsec, compared to having official CVEs.
- josh: In the past have been asked to have something like cargo deny officially part of cargo, but things like this identify the kind of quagmire that has. But perhaps there could be a subset of less controversial things (like checking licenses) in cargo, and have the more opinionated parts farther away.
  - jacob: Would love to have a plugin system for auditing dependencies. That could influence the resolver to avoid the problems.

2024-04-02

eric: status update on implicit dependencies https://github.com/rust-lang/cargo/issues/12826
- ed: Prototype lint has been merged. Will follow up the relevant tracking issues with todo items.
- weihang: Mostly a proof of concept, more work to be done (behavior not complete).
epage: nested packages
- https://github.com/rust-lang/rfcs/pull/3452
- Is it worth it?
- Can you identify any other concerns that need to be worked out?
- josh: We've seen proposals in this general area for a long time. Is there a 60-second description of the problem?
  - ed: Copies path dependencies into published .crate files. Requires an opt-in via Cargo.toml fields.
  - Help with build times, publishing process, help break dev-dependency cycles.
  - If publish="nested", then it cannot be published by default.
  - Does not directly help with binary/library dependency split.
    - There is a benefit if you have a lib dedicated for the binary, and don't want to expose it publicly, or have semver guarantees.
  - Could use this to support doctests by having a library and making the binary's source just use lib::main;
    - Aside: supporting doctests in bins could be supported by having the doctest expand to an inline #[test] instead of a separate binary
- rustin: How does this compare to namespaced RFC? Couldn't the internal packages be published within the namespace, and limited to only being used within the namespace.
  - josh: Some kind of pub moniker that indicates that it only exists for certain crates (in the namespace?).
  - ed: a benefit of publishing everything in a .crate is to avoid needing to deal with version numbers, metadata (like licenses). Workspace cargo publish can help, but there is still overhead for managing the set of packages.
  - jacob: for the pub idea, can this be enforced?
    - ed: If rustc is aware of the namespace, it can be enforced.
- josh: Can you combine this with bindeps, and private crates, can you have an unpublished crate that you depend on as a bindep? Build a binary and run it from my build script.
  - ed: Yes, that should be supported.
- Jacob: Could use this to get build scripts from some other crate. (Needs bikeshedding.)
  - Josh: This would be a clearly better replacement for metadeps.
- ed: Regarding concerns of using this for vendoring:
  - This does make it easier to vendor, but you can still vendor through other ways (like copying directly into src, or just renaming and publishing those).
  - jacob: cargo vendor makes it a little difficult to do things like modifying vendored dependencies. Nested packages goes against that intention of discouraging that.
  - josh: Good for temporary vendoring, where you are waiting for a patch to be published.
  - jacob: Considering extensions to cargo to better support vendoring, and things like upstreaming changes.
- arlo: Question of how merging in the index and cargo.lock, and relation to sbom and licensing stuff.
- josh: classic problem of ratcheting best-practices upwards. For people vendoring already, this is an improvement, for people doing it "better", keep doing it that way.
  - For best practices, encourage how we expect it to be used. For example, -sys crate for an FFI library could be a private crate. Include the considerations for when to use these nested packages.
- weihang: Is this trying to solve behavior in cargo or rustc. For example, macro or ffi could be rustc. But for publish it is for cargo. It seems to be solving multiple problems that covers both.
  - ed: This is a principled solution for multiple situations, without having to add new concepts to rustc to add it.
- rustin: What is the boundary of the best practice for promoting a nested package to public?
  - ed: Depends on how your code evolves. Example: serde+serde_derive. If those were published together, could later decide there are benefits to having it separate, go ahead and do that.
- eric: Question about supporting a workspace, where there is more than one public package and private shared ones. That won't work if those shared packages are vendored and
- eric: Overall unease of the amount of complexity in cargo. Acknowledges it does solve some issues.
- arlo: Concern of the complexity around teaching users which model and process to use. Can the open namespace solve some of the issues.
- weihang: Can there be non-member nested packages?
  - ed: Yes for path only.
- josh: What are the next best solutions as alternatives?
  - For example, in namespaced if it could have a public/private distinction.
  - ed: There isn't a specific alternative to significantly reducing the overhead for splitting something into separate crates.
- arlo: (While unstable) If crates are published with this, and we remove it, would those published ones be broken.
  - eric: Updating crates.io is usually a high bar, so in the past we haven't updated crates.io until we are pretty confident we want to move forward, since it is a permanent decision.
  - josh: Do we have to update crates.io? Can cargo just isolate the changes in Cargo.toml?
  - ed: crates.io could check for the unstable feature, and use the upload JSON instead of parsing Cargo.toml for this.

Cargo team meeting notes 2024 Q2

2024-06-25

2024-06-18

2024-06-11

2024-06-04

2024-05-28

2024-05-21

2024-05-14

2024-05-07

2024-04-30

2024-04-23

2024-04-16

2024-04-09

2024-04-02

Read more

Cargo team meeting notes

Build Times: Cargo Perpsective

2025 All Hands Topics

This Development-cycle in Cargo: 1.86