Josh: Would negative features (starting from default and subtracting) need edition support?
ed: Probably not.
Josh: Changing the default of default-features seems like it would likely need an edition, if ew even had consensus for that. But it does seem like subtracting features should need an edition.
Jacob: Uncertain wants to change the default, but if we did, would expect a three-year process for deprecating the default of default-features.
Weihang: Doctest cross-compile.
Eric: I think the main concern was enabling it will likely break a lot of projects. Do we need to add a new option to disable it?
Weihang: Is there any opinion from rustdoc on stabilizing the required options.
Ed: precise flag to opt-in to pre-release. One minor corner case. The overall approach is that the semver version req check will have two functions. Normally it doesn't do any special checking of the pre-release. One problem is if you have a library with libgit2, like >=0.11,<0.14, saying they are compatible with multiple incompatible versions. That will match 0.14-alpha.0 since it encompases. An exception is that less-than won't match pre-release.
Jacob: Less than <3.0.0 would not match 3.0.0-alpha0 (by essentially being <3.0.0-0). If there are any pre-releases in the requirement, then we honor that. But if not, then it doesn't include that.
Cases:
>=0.11,<0.14 expands to either
>=0.11,<0.14.0 but catches 0.14.0-0
>=0.11,<0.14.0-0 (preferred)
Problem: >0.14.0-0,<=0.14.0
Arlo: Is this all in relation to the --precise flag?
Ed: Mostly, we might also have a --prerelease flag to say "allow for eveery"
Ed: If we don't change the interpretation of < ranges, then this likely won't need an edition change.
Josh: strip on release? strip-to-separate-file on debug?
Ed: Does strip-on-release need an edition?
Ed: Can we change the default for strip when debug=0?
Josh: Thinks we can get away with debug=0 implies strip. There will be a lack of backtrace information (for std).
Arlo: You already don't get good backtrace information except for std.
Arlo: strip to a separate file sounds like a bigger change and may need an edition.
Uncertain how common it is on non-Windows platforms.
Josh: On linux it is common to have debug in a separate file. Sometimes when debugging, you don't separate them, but when distributing/installing, they are usually separate.
Josh: Part of an advantage to stripping separate, makes the binary substantially smaller, gives you the option to use them or not if you see fit.
Ed: Single binary distribution use case (like GitHub, cargo install).
Josh: You want your binary to be an order of magnitude smaller. You either put those debug in a separate package, which you can elect to distribute (Only used when debugging a crash.) Or you hold onto them and use them when debugging submitted crash reports.
eric: Is this just dev profile, or when debug>0, or release?
josh: Changing the default value of split-debuginfo.
eric: We changed the macOS default without any fanfare.
eric: Doesn't know the likelyhood of that breaking something on linux.
Josh: One example is if in a build system it wasn't prepared for having them in a separate file, and wouldn't know to pick them up.
Jacob: Might be easier to ask for forgiveness.
Josh: If you need the old behavior, then you can switch the setting back.
Ed: There is no edition for a workspace.
Jacob: That sounds convincing to not use an edition!
ehuss: GSoC
Goal: Ask if anyone wants to mentor.
Ed: Is willing to help mentor.
Josh: Was a mentor in the past, had mixed results, some very good and continued with the project, and those that can't quite yet write code.
Jacob: There seems to be a relatively high retention of people who stay involved, but still a low number that can be difficult on the mentor.
Jacob: Ok for other rust things that don't have a legal entity can be handled under the rust-lang umbrella.
Jacob: The clap auto-complete engine? Lots of closely related things come to mind.
Where people can jump in with high value, and focused contributions.
Considering the past roadmaps had big visions, but had a possibly disappointing outcome when things didn't happen.
What needs polishing up to publish this?
Gap between the project and the community. The commits in TWiR don't tell users where things are going.
Every 6 weeks at the release, post a summary about what we are working on and the discussions we've had. Summarize the last 6 weeks of development. Helps build a closer connection to the community.
Jacob: Sounds really useful. If you are willing to do it, that would be great. Also tracking follow up on the things that we intended to. Good check-in on those things we didn't follow on.
Ed: This could be on the inside-rust blog. "this is an experiment", set expectations.
What kind of notice would people want, like a draft for getting feedback?
Jacob: Alternative would be to put it in the cargo wiki.
Ed: Develop on the wiki, and then push to TWiR, and start a new one?
Jacob: Not sure it needs to be on inside-rust unless we're really doing things to be more public.
Ed: Intention was to connect with the community.
Weihang: Concern of it being a burden. A mechanism for collecting people's ideas?
Ed: Have the team members collect the things they've been involved with.
Jacob: Cargo-meetings Zulip thread that could collect ideas to put into it.
Ed: Does this meet the level of every 6 weeks on inside-rust?
Rustin: On the wiki page could be difficult to find. Personally doesn't ever look at the wiki pages. If you are not a maintainer, can be difficult to comment and give feedback. Maybe have a personal git repo or rust-lang org? Then track there, use mdbook to publish.
Ed: If I'm doing the work, I'll say no to that, since that would require setting up various things. Creating a separate space is a higher barrier to entry. Especially if this is an experiment.
Jacob: Do what you want, and then we can figure out where to publish it, and then can change decision later.
Eric: What were the objections to publishing to inside-rust?
Jacob: Didn't want to put pressure or expectations on Ed.
Ed: Is fine with publishing it on inside-rust with a notice about expectations.
Extending to yanked with a warning. Several corner cases that could benefit from this.
Arlo: Sounds good with a warning.
Rustin: What are the use cases?
Arlo: The problem now if you need to use a yanked version, the only option is to manually edit Cargo.lock.
Jacob: When there is a disagreement by the user of whether or not they are OK with using the yanked version
Like crypto packages that yank older versions.
ed: Would prefer it to be automatic with --precise, not requiring any other flags or requirements. You're already telling cargo what you want.
Josh: As long as there is a loud warning, that seems fine.
Arlo: Making people look up the exact version is enough to know that they want the yanked version.
Ed: Would prefer not to have interactive questions.
Eric: This sounds good to me. I don't have context on why yanked was designed the way it was, it was before I joined.
Josh: Could ping Alex and ask context on any reason yanked worked, would this be a bad idea? Not necessarily beholden to the people who worked on this in the past, just check if there is any historical context.
Jacob: The community isn't the same when yanked was added, the community norms were different.
2023-12-12
epage: FYI pinged apiraino about T-compiler not talking about packages-as-namespaces despite being on their agenda for 6 weeks
Sounds like we are both on board with telling Tobias to move forward without them, similar to how other T-lang proposals don't block on T-compiler
Adds a new resolver version that changes the resolution behavior of pre-release requirements to be strictly equal by default (does not pick newer pre-releases).
Last activity from author was May 2022 (18 months).
Last activity from cargo team was Eric on Nov 2022 (12 months).
Eric and Ed had some suggestions (bottom of PR threads), but there were some significant concerns, risks, drawbacks, and disagreements.
eric's proposal: Close as postpone, as it isn't clear which path this should take, and at the moment nobody on the cargo team has the capacity to adopt this at this moment. Recognize that this is a significant pain point for the community, and that we would really like to see a better solution, but it isn't clear which direction that would be.
jacob: In a fog of war, it could be the next step we take, but it is a lot of complexity to add, and a lot of tricky corner cases. Seems like a hard next step.
Scott: Confirm: What is a pre-release?
jacob: In semver, you can add a string at the end like -alpha.1, but the semver spec isn't particularly clear on how to handle those.
When should you be allowed to have multiple versions, etc.
jacob: Would have liked if cargo had handled this differently in the past, but uncertain if the transition cost is worth it.
Josh: In general, the transition cost might be worth it. How close is the current behavior to broken? We've never worried about stability when going from "not broken" to "broken".
Jacob: Unfortunately, while the current behavior isn't great, if we change it to "one version only" that will break some builds.
Weihang: A lint system would offer a warning if a pre-release isn't pinned.
Jacob: That could be a good transition plan, until we know exactly where we are going.
Ed: Uncertain it is justifiable to break, since the current behavior is somewhat in the middle.
Scott: Wonders how often pre-releases are used as opposed to git dependencies.
Ed: People don't use it because it is broken.
eric: doesn't consider pre-releases that broken if you consier pre-releases compatible (that is, if you are only making bug fixes and such during that phase)
Ed: Unstable feature flags might be a better approach for some cases, which allows incremental experimentation.
Josh: Issue that it is not standardized.
Ed: There is an issue for making it part of the feature system. This was not included in the feature RFCs due to concerns of bikeshedding.
Josh: Things the lang team would like to see is the stability markers being something people could use.
Jacob: Not entirely a complete replacement for pre-releases, some code changes are major.
Jacob: propose postpone, and add a lint when we can to specify semver tag.
Ed: If other features (like stability and accessible) can handle the use cases to reduce the need for pre-releases, that would be good. Then we can look at the remaining use cases.
Josh: Agrees with including a lint. Not exclusively =, just not the default semver req.
Scott: How fast do we want that done?
Josh: If we had a PR tomorrow, here is a lint, we would review and merge it.
Ed: In terms of prioritization, would want to be able to hit 2024 edition.
Scott: January or February?
Jacob: To postpone we don't need the lint available, just not complete vaporware.
Josh: In an edition, can reject certain kinds of version requirements that we don't want to ever use. Like a fully open one like >0.
epage: conceptually, this makes sense because a version requirement says its compatible with pre-releases newer than the current version, its just not preferred and should require an opt-in
Otherwise, too complex to get unification for trying out a pre-release
Patching a git dependency would be a workaround though can't be published
Version can't be bumped though
Shifts pre-release "compatibility" logic from semver package to callers to decide which policy is needed when
epage's proposal: Close due to complexity being foisted on cargo to accomplish this. The invasive aspect of this.
Jacob: Advocate: The end user should be able to override a dependency or force what they want if they know what they want or will work. Maybe in a patch section?
Would need to be sticky or else next call would revert it
Ed: Possibly bigger problems with pre-release that need to be resolved first, like the operator behavior.
Ed: Maybe the resolver could have controls for what is preferred.
Ed: Pre-release behaves like yank. Pre-releases and yank both act like they aren't there.
Ed: Concerns around auditing a lot of code. Things like semver crate might need a 2.0 since it is such a large change. Or a new function like matches_with_prerelease, etc. Deep changes in the resolver. Potentially impacts any tools that work with dependencies.
Ed: cargo update and cargo generate-lockfile could have flags.
Jacob: The resolver needs to know before it starts what overrides will be allowed.
Ed: As a feature this makes sense.
Jacob: This is complex because it needs to be stored (in Cargo.lock?).
Eric: What about asking for a prototype so we can see the level of complexity?
Ed: Will follow up with jacob to figure out what direction we could possibly take and then follow up with the author.
Ed: Recommends waiting, is doing an update and re-reviewing. Frustrated with some of the comments. Focusing on use cases. Thinking about pushing to another branch for review of changes in a smaller group before going to the rfc repo. Whether or not to keep the current default is the major issue.
Josh: Happy to review chunks as you go along (instead of waiting for everything).
Ed: The writing out process is helping clear up things.
Josh: Are you also planning to capture what the goal we are trying to solve? What is the precise use case?
Ed: Yea, the new writeup is covering that.
Jacob: If the problems that remain are people (as opposed to the points themselves), would it make sense for someone else on the team to respond to feedback? To make sure people are heard.
Ed: Makes sense. Cautious with being intentional. Concerned about comments being too concrete, would like to make it clearer that it is a process for figuring things out.
Jacob: Point on changing the default, and if now seems too soon, that could be part of an edition change so that it is very clearly, loudly, and publicly communicated.
Ed: If we change the default, it needs to come with fanfare so that people are aware.
Josh: Concern, 2 or 3 things people were talking about (cross-purposes?). "Here is a thing that I want", or "This is a half-solution to caching build problem". What is the motivation for this (other than caching builds)?
Ed: There's no shared caching in this solution (since each workspace gets a separate directory). It sounds like there was confusion in the thread.
Per-user caching would relieve some of the pressure on target directories, but not 100% of unloading target from the local directory. (Since local things like final artifacts wouldn't be in a shared cache.)
Arlo: What are the use cases?
Ed: ZFS type situations where you want cache in one kind of file system and sources in a separate fs. Or other situations where permissions need to be given for running binaries (which makes it impractical to run cargo with build scripts and such). Or a fast or temporary filesystem for the cache, and source in a slower FS.
Jacob: Temporary FS automatically cleans itself which is nice.
Josh: Or rm -rf of target directories when updating toolchain, easier when all in one place.
Arlo: Can this be set in config.toml?
Yes, build.target-base-dir
Ed: How to find the path to final artifacts in the target directory?
Some people may not like having symlinks.
Currently can use cargo metadata, perhaps can improve that to make it easier.
Josh: The backups motivation is tenuous since there is already a solution for that.
Jacob: This could be an 80/20 solution to get most people unstuck, but not 100%.
eric: Was there any discussion about making the string more extensible, like having /my-cache/$HASH or whatever.
No recollection of that discussion.
Josh: What is the actual naming scheme?
There is a three-level hash ($CARGO_TARGET_BASE_DIR/hash[:2]/hash[2:4]/hash[4:]/...)
(Eric doesn't see what the hash is exactly, though.)
Current proposal does not allow relative paths.
Arlo: Should there be reserved characters for the path if we want to add placeholders later?
There's something similar with the dl download path in the registry config, using curly braces. But if no curly braces, then it defaults to appending to the end.
Ed: Will look into reserving curly braces.
Arlo: Wonders if substitutions would make more sense for CARGO_TARGET_DIR and not as much for CARGO_TARGET_BASE_DIR.
Ed: Do we really need to wonder about backwards compatibility with things like adding curly braces in a config path?
Jacob: The number of users has increased significantly since the early days of cargo, making it a little harder to make backwards incompatible changes.
The ability to use .patch files for [patch] table entries instead of requiring a full copy of the dependency.
Posted September 2021 as a "Draft" (25 months ago)
Last activity from author was Mar 2022 (19 months ago)
Last activity from cargo team was Josh on Nov 2022 (12 months ago)
eric: I think the majority on the cargo team are positive to add something like this, but there are various details to work out that haven't been addressed.
eric's proposal: Close as postpone, make it clear this is something we would like to see, but that the RFC hasn't made progress. Capacity-wise the cargo team isn't able to put it on their roadmap at this time. When someone is able to champion it, then we can likely pick it up again.
ed: Also wants this, but ok with closing. Wording: Say, it is approved for unstable experimentation, and then an RFC would follow up for stabilization.
Arlo: How does this work with patching Cargo.toml?
Josh: Probably don't want to go into deep-dive if author isn't involved.
Make it clear this isn't a "no", this has a lot of details that need working out, we are generally in favor.
Weihang: Last time we talked about this was around serde issue? Is this urgent to fix?
eric: My position is that this RFC is just a convenience. You can still use patches with the full source in your local directory.
Jacob: A generalization, the ability to load patches while resolution is happening. A plugin mechanism that could handle this and other circumstances.
The ability to detect the OS version in code (cfg!(os_version_min("windows", "6.1.7600")))
The ability to specify the minimum OS version in Cargo.toml, and generate an error if the targeted version is too new (similar to how rust-verison works today). The minimum version is the max of all transitive dependencies.
Adding command-line options to rustc and cargo for setting the target OS version.
eric: Uncertainty about how this would work with the standard library. It sounds like you wouldn't be able to set the floor above the standard library (which would currently be "Windows 7"), which seems to significantly limit the usefulness.
Last activity from author was Feb 2023 (9 months ago)
Last activity from cargo team was Eric on Jan 2023 (10 months ago)
Last activity from libs team was thomcc on Jan 2023 (10 months ago) (asking about macOS deployment targets).
No activity from the lang team.
eric: I think there is a general desire to improve support for handling different OS versions and components (like libc versions). However, it is unclear to me if this is the best general solution.
eric's proposal: Close as not having the capacity at this time? Make it clear this is something that would be useful, but it's not clear if this is the best general approach?
Or is there some way to split this into smaller pieces? Is it possible to be useful without cargo support?
Jacob: Q: A problem with build-std is that if you build std, the newer code paths you want to set aren't there, how would this support those?
Eric: There would be additions to std that would allow it to conditionally build for different OS versions.
Jacob: So there is a chicken-and-egg problem, since std won't support this without it.
Josh: Agrees, without build-std it is difficult to take advantage of this.
This could also help with runtime detection.
Arlo: As a feature of the standard library for helping users do runtime detection.
Scott: Why has build-std stalled?
eric: Because Alex left, and nobody else has stepped up. (Particularly, support from the libs team.)
Josh: Libs team didn't have a strong opinion except for the stable surface area. Would be thrilled to have someone come up and say "here's a proposal", but not necessarily driving it.
Eric: There are implementation aspects of std that I don't want to work on by myself. There are a bunch of hard questions to answer on how that will work.
Ed: How build-std can affect other things: The standard library has its own lock file, separate from your own project. With respect to stable ABIs or dynamic linking (ex bevy), stabilizing a subset of a package with its own lockfile, and then more dynamically link against that (which also makes it easier to cache it). This could be generalized for other projects.
Eric: Post a note about it postponed, and possibly split up.
Adds --coverage CLI options to cargo to tell it to generate coverage data.
Last activity from cargo team was Eric on Sep 2022 (14 months).
Last activity from author was Sep 2022 (14 months).
eric's proposal: Close as postpone with essentially the same statement as https://github.com/rust-lang/rfcs/pull/3287#issuecomment-1259949035. We would really like to see first-class coverage support, but it isn't clear how best to approach that when there are different coverage tools, and the LLVM coverage tools aren't necessarily stable (though in practice they generally are). Capacity-wise the cargo team isn't able to put it on their roadmap at this time.
epage: "LLVM coverage tools aren't necessarily stable" though my concern is about other codegen backends
Jacob: Why was -Cinstrument-coverage stabilized if it isn't perfectly stable?
Josh: Example of debuggers, where rustc may change the debug format (like dwarfv5) which could just break older debuggers.
Josh: If our only concern is around variations on tools, that argument was had on the rustc side. The same answer for cargo would be fine. But if there are other things, those sound like things worth concerning.
Ed: Postpone, but approve for experimentation?
Currently handling package-specific rustflags is awkward.
Arlo: Enabling other crates to plugin their own coverage support.
I feel like "develop against MSRV" will be the safest option
However, "develop against MSRV" will mean people using cargo generate-lockfile to test against latest deps will need to change their job, likely not many
some projects have CI validate MSRV separately from development (separate lock files).
Another suggestion was to make the preference "sticky" in Cargo.lock.
Arlo: Is it possible to decouple cargo and rustc version
not really, they are tied together
If the tool knows the answer, should it pick that answer?
josh: If the user specifically said to use a specific rust-version, then cargo probably shouldn't pick a crate whose rust-version doesn't work with that.
arlo: build.resolver.precedence could be confusing with rust-version (specifying it twice, or two different versions).
scott: Is it possible to tell rustc the version, and have it tell the user it the version of some item is too new (from #[stable])?
ed: Was also thinking about extending #[stable] to allow users to use it in their own crates.
arlo: Wouldn't this also apply to new language features?
ed: Lots of things, like const changes, etc.
jacob: This might be better for clippy.
josh: best effort here. The only way to really know if something works with 1.x is to build with 1.x, but we can at least attempt to tell people that something won't work.
arlo: rust-analyzer could also exclude "too new" items from auto-completion
josh: or deprioritize them. Or update Cargo.toml if you use them.
rustin: typically only uses nightly. When CI fails due to MSRV, needs to manually make changes to make it work, which can be painful to determine what is allowed or not.
eric: Is the proposal to add this config option now, or later?
ed: Would be important for certain workflows. If it is in config, that just implies a preference.
Perhaps not enough defined around this flag around the workflows and use cases.
This could be made available, and made prominent in our CI documentation.
This is a rollout plan, but not necessarily the one that we should do.
Possibly have a separate config for cargo install. Doesn't want to tackle the security concerns around that.
Rollout is config first, and then roll out msrv-aware later (which might take longer).
scott: Would this be backwards compatible, for older versions that don't have this?
A problem is that if using an MSRV resolver in CI, and a user uses an older version to run cargo update, the resolution won't be the same between them.
weihang: Would it lead to a situation where people don't know how to set their msrv. They just set latest stable. Then there are complaints that packages are too new and they can't use them.
ed: That is essentially the situation today (without msrv resolver).
weihang: Perhaps someone just doesn't care about the msrv of a dependency.
rustin: Why do we need this solution to use the latest dependencies in your project? Wouldn't using latest break in CI? What is the use case for selecting latest versions?
ed: Having a CI job to pick the latest was to deal with the issue of previously not recommending not checking in Cargo.lock. Having two CI jobs was to try to cover both cases, to provide an early notice if things weren't working.
arlo: Would it be possible to have MSRV the default, and then have a CLI flag to pick the latest (why have a config to do this?).
A use case is to always be latest (in local development), and they don't want to constantly pass in a separate command-line flag.
arlo: Be careful about how it is named. The current example seems confusing, and may want to bikeshed the naming.
Scott: Have a separate dev version? The difference between local development version, and the published version.
ed: Concern about the complexity.
Weihang: Should there be a policy of what the community should follow?
ed: Doesn't want to pressure people to use an msrv they aren't going to verify. It's going to be difficult to get people to agree in general.
weihang: May not be too severe with --ignore-rust-version?
Still concern, people may set it arbitrarily.
Jacob: The people with hard requirements may not be talking to us.
There's also people who are using rust incorrectly, such as using debian-stable rust release for development (which should only be used for installing).
cargo msrv can help you determine what your actual msrv is.
ed: My msrv changes, arbitrarily raised when a PR needs some new change.
scott: If no policy, say why there isn't a policy. If we ever have a policy, crates.io data says that most people are in the last 6 months. 95-96% was debian stable or newer. Some of the data is not very reliable. There is a route to help people pick one.
eric: confused, isn't msrv-aware resolver the whole purpose of fixing this?
jacob: What is the minimum thing to stabilize?
ed: Enable msrv by default, but allow an option to use maximum version.
ed: The resolver previously would error, but now it tries to pick the best.
Josh: one issue is getting people to set rust-version at all, which might put pressure on people, which might not help if it is not validated.
Ed: Will follow up on the pre-rfc, and deal with the bikeshedding of the name.
Ran out of time to talk about the "what if rust-version isn't specified" case, Ed will follow up with Jacob and possibly others.
How to treat no MSRV
MSRV could be added, removed, re-added, etc
If we treat it as compatible:
If no MSRV and then specify it later (without effective MSRV changing) then the no-MSRV version will be picked and it will give a bad compilation error compared to picking latest and saying its not compatible
If we treat it as incompatible or semi-compatible
Removing MSRV means old versions will always be picked, effectively coercing people into never dropping it
Maybe within a package this wouldn't be too bad (minus mistakes) but if abandoned names get transfered…
What if interpolate it by doing a MSRV look-ahead followed by look-behind scheme?
Likely would need to be smart to avoid O(N^2) lookups when no MSRV is set
2023-11-21
eric: semver compatibility:
Concern that as we add more crates that it will get harder
scott: debuginfo syntax change: be more mindful of during review
For manifest parsing, there was an msrv issue where publishing with an older version would strip.
Slow march of getting better
weihang: cargo-credential issue, issue that cargo depends on two major versions of one dependency. cargo-deny can catch this, disallow depending on two different version. Can we adopt this, and would help us better understand these tools and how it might be something that could be adopted. (or maybe some other tool)
jacob: Simple solution like scanning cargo tree is also an option.
eric: checking duplicate dependencies wouldn't have helped in this case, since there weren't duplicates in a single tree (it was 0.74 -> credential-* (new version) -> credential (new verison))
eric: thinking that public/private dependencies might help if that can be plugged into cargo semver-checks
jacob: Can we test with things that depend on cargo, and see if they break after publish?
eric: another complexity is that this was an older version of cargo, do we actually want to support or put much effort into older versions?
weihang: adopting this kind of pattern in CI
jacob: Figure out what the pattern is by dogfooding it, and then make it shareable. Could help us uncover what needs to be added to support it.
jacob: also ties into workspace publish. It will want to behave as-if path dependencies were published.
weihang: cargo-vendor (source replacement) won't work with path dependencies.
jacob: Can use a proxy registry pretend to have everything published.
eric: there were several different cases over the past year, where each breakage was different than the last, and no one solution may completely help
weihang: Collect major consumers
scott: can it run cargo package
eric: yea, to be essentially equivalent, that might be necessary
scott: Can create a new pseudo-official extension that could implement this.
eric: will try to create a list of the changes that caused breakage to better think about how to fix it.
arlo: The three cargo crates could just be brought into cargo itself.
eric: minor concern about harming the build times of the cargo crate itself. Probably not a major issue, since these are small, but it would be nice to try to keep things separate.
scott: workspace inheritance could have grouping, so that you could bump the version of multiple things at once.
rustin: how to manage breaking changes in cargo library in PRs? To tell people that this would be a breaking change.
josh: wondering if we could be more careful with what is marked pub (as opposed to pub(crate))
API of cargo library as a package manager being public versus the CLI part being more private.
eric: there was some intent on having it public so that people making their own cargo commands could reuse it so they looked and behaved the same as built-in cargo commands.
Summary: lukewarm on the syntax, largely because of future trajectory. Much debate about whether to validate the tag (cargo) in rustc or in the interpreter.
One point of view: these should always be "owned" by the interpreter, which should reject anything it doesn't understand. (In this case, presumably the block should be rejected if there's no interpreter.)
Another point of view: these could be used by other Rust tools, but in that case who should validate that the block is for a known tool?
Lang team potentially willing to make a small incremental step, but unenthusiastic (and does not have consensus) about future trajectory.
Josh and Ed will work together to get a more concrete proposal to tighten up the future possibilities, be clear about the one narrow thing they are asking for.
Scott: Asking about implicit workspace inheritance.
Example: Not needing to specify lints.workspace = true in every Cargo.toml
Josh: lukewarm. But feels unpleasant from a debugging POV, understanding where something comes from. A little magical.
scott: dependencies probably wouldn't support it, only workspace.package stuff.
Josh: Could there be one line to say "bring in all this stuff", so that there is a little bit of explicitness, but lighter-weight.
Arlo: cargo base path to help reduce repeating the path in path dependencies.
Jacob: Uncertain what the remaining use case is (thinks this particular concern was resolved in Amazon via patch-in-config)
Scott: One use case: Have a directory with a bunch of packages, and you want to be able to easily depend on something, and you can just say the package name, and cargo would know where to get it from the shared directory.
Jacob: Just sugar might be a hard sell
Question about edition dates:
Current outline would be to have designs approved by Feb at the latest. Implementation should be finished on May at the latest. The release hits stable in October 17.
An edition change is fairly complicated to not be noisy for everyone.
Josh: The reason there are edition lints is so they have advance notice of the transition.
The lint could be in the transition lints (which are only shown when migrating).
Don't lint in advance. Only apply fix on cargo fix --edition.
Or, leave it out entirely. People will then encounter the error on cargo publish. Doesn't necessarily think this is a good option.
Or, avoid the migration for already published crates?
Doing on the actual migration might be difficult. Don't know where it is going to publish to.
Weihang: Interactive question in CLI of what you want the publish setting for?
How would this interact with --interactive, which would not be enabled by default?
Jacob: cargo fix --edition would add publish=true which is the current behavior. That won't break anyone, but that means everyone who is upgrading won't get the benefit of the new default.
Josh: Likes, optimizing for low friction. If someone has a crate that already has enough code that they are doing an edition migration, they are probably already published, or this isn't a concern for them.
Should we change the default?
Jacob: If he had a time machine, the correct default would be false. Fix it now, or live with the current behavior forever?
Reasonable either way. Papercuts in tools are common and can live with it, but an overall improvement could pay itself to overcome the drawbacks.
Josh: The padlock that stops you from publishing should be the visible thing. When you go through all the other settings you need to add (license, description, etc.), you can just delete the publish field. It will also be very obvious if you forget to remove it when you publish.
Ed: Doesn't mind cargo new setting publish=false. More concerned about the linting, where various different lints could be tied to the publish setting (like telling you about missing description, etc.). Cargo explicitly knows that you want it to be publish.
It's nice not to require a bunch of specified fields for things you don't publish.
Not quite sure if it is enough.
Scott: cargo new change is good for new users. The pain of changing everyone over is worth it.
Students using cargo for the first time could help with mistakes.
Rustin: Not a strong opinion.
Arlo: The edition helps with making improvements for this. Agrees with scott on the improvements.
Weihang: Same as arlo :).
eric: Is there a survey of how other tools handle this?
No, can ask user for survey.
eric: Wanted to double-check, feeling on original issue was that there is already a gauntlet you have to go through to publish something, and so the risk of accidentally publishing seems low. Also, the original position was to make it easy as possible for people to publish. It's OK for anyone to publish, and encouraged.
Ed: Automatic workspace inheritance, publish can be inherited. Some people have different feelings about publishing (is it ok to use names on crates.io?), some don't mind, some might feel uncomfortable about doing that.
Ed: Which user are we optimizing for? Those that are publishing, or those that aren't.
Prefers avoiding boilerplate. If we are optimizing for people would be publishing, then we would pre-populate all the other fields they would need.
Josh: Could potentially stop putting publish=false in cargo new after the edition transition that changes the default if we decide we don't like the boilerplate.
eric: Survey who actually sees all@
Ed: Notices them only when emptying spam.
Scott: 80% of all@ is spam (has a filter).
Arlo: Didn't get all the messages.
Weihang: Doesn't get any important messages, all goes to spam.
Eric will try to relay messages in the meeting.
epage: meet next week?
Nobody has indicated they will be gone. It's ok if a few people are gone. Should go ahead with meeting.
epage: release notes?
Concern about the rust-lang/rust release notes were just copies of the PR titles, which was not very clear. Also didn't use the work that weihang already did. What qualifies for something going into the release notes?
josh: The script just queries for relnotes tag. If we want this work the same way, they should be tagged.
Scott: Should we have the team go over what needs relnotes?
josh: Usually there is some curation during the relnotes process. Best to have people think about this when reviewing.
ed: The script also picks up FCPs (to-announce), and some of the internal changes made it in due to this.
eric: What is a proposal for improving this?
eric: Propose having someone (weihang?) post a comment on Zulip with a copy of the curated release notes that we want included that they could copy and paste.
rustin: Give guidelines for what is included in the release notes, that way it gets updated as it goes along. But can cause conflicts.
scott: Somehow mark what is included.
Ed: Probably should include release team in discussion.
Weihang: Doesn't think automated solution would work, since it can be difficult for new contributors.
PR reviewers can change the PR title to something that makes more sense.
rustin: Kubernetes community has a specific form in the message that has the changelog entry, and it can't be merged without it. Some downsides is that some people don't know how to write it. But a benefit is that it makes sure to include it.
Not bumping MSRV was important if we were deny-by-default
Might still be helpful for people adopting it early
Still worth using pub just to avoid MSV bump?
How strong do you feel about pub vs public?
How strong do you feel about msrv support of this feature?
Jacob: Do we want people to use it, even if their msrv version is too old and doesn't understand it.
A concern about missing some detail about running an old cargo version that is ignoring the field.
Arlo: Examples of behavior differences based on rust-version?
Not exactly. Lints is an example where it is ignored when running on an old cargo, but the most recent version of cargo doesn't have a difference in behavior.
Bikeshedding: Two people mentioned a preference for not using pub
Arlo: Also kinda likes the longer more explicit form, since longer forms are typically used in the dependency table (like optional, not opt). But is also fine if using pub for compatibility reasons.
Scott: Explicit is the rust way. But when repeating something a lot, shorter forms make sense. But probably the short form isn't as important here since it isn't repeated that much. Leans toward the longer form, but is fine with both.
Ed: Explicit isn't the goal itself.
Ed: Clarification: rustc lint is allow-by-default, but switches to deny in 2024 edition.
Scott: If it is mostly used in the edition, then it seems unlikely that people stuck on older editions will use this feature?
Ed: Many of the fundamental crates have longer msrv's. This would prevent them from being able to opt-in to it.
Eric: Didn't intend for concerns about how rustdoc works to be handled in the RFC. That is something that should be figured out in the implementation phase.
Eric: rustc changes might be significant, to handle things like diagnostics (which refer to the crate name), etc.
t-compiler didn't have time to dive into the RFC in their meeting.
Ed: My open question is handling FORCE_HYPERLINK environment variable, since that isn't really a standard. A copy from a node package that started using that.
FORCE_HYPERLINK is only read when you don't set term.hyperlinks (the "auto" mode). If you explicitly set true or false, then that takes precedence.
Currently using the auto-detection logic from the supports-hyperlinks with one override (iTerm2 handles file:// URLs in a different way that doesn't work very well).
iTerm2 tries to SCP, which prompts for a username. If the hostname is not specified, it opens inside Finder.
Arlo: Does it work in VSCode terminal?
It opens the raw HTML file in the editor.
public/private dependencies
Some people need to re-read it.
eric: Couldn't remember why the original RFC had resolver integration.
Manish recommended keeping the FCP to crates.io but getting informal agreement from cargo and compiler
Jacob: On Cargo's side, we just need to support :: and package names? Yes.
Ed: This also affects how things are sent to the compiler.
Some uncertainty about arbitrary nesting. Current RFC has just one layer.
Scott: Could see opportunities for multiple levels.
Ed: This is a semi-open Rust-lang namespace feature.
This is more of a focus on the API, does it make sense to put things together in the same namespace. Not an org-level namespacing.
Weihang: How would this interact with namespaced feature syntax?
Jacob: Tie it to removing weak feature change in edition?
Ed talked with Manish about tying it to a minimum edition.
Eric: Why would it be informal agreements?
Concern with overthinking the design.
Eric: Wondering if the language team wants to weigh in?
Josh: Although it is a language change, doesn't think the lang team wants a formal weigh-in, but would just want to check in (poll or ping them, ask them for any concerns).
Questions about name collisions.
Ed: Recommends adding a comment about the feature syntax.
Eric: Would like to see at least cargo and crates.io for approval, and lang and compiler to at least have a check-in.
Eric: Will try to find time to review.
Ed: Will create an issue to have an independent FCP.
epage: --check-cfg: not finding notes, where are we at with that?
Weihang: Vaguely remember specifying in Cargo.toml or profile.
Eric: Arbitrary configs
Those should be specified in build scripts. There was talk about having declarative specification in Cargo.toml, but we may not want to be doing it.
Eric: The concern was validating names. Some people use RUSTFLAGS for passing in --cfg (like tokio has one), and that would show up as a warning for every crate in the graph.
Not too hard, but will need to touch all the places it reads it.
Ed: Might be weird on all commands, should we instead encourage these people to use cargo update --ignore-rust-version in place of cargo update and cargo update --workspace --ignore-rust-version and after touching `Cargo.toml
Alt: we put rust-version = false in the lockfile so once its used, it automatically applies to future commands
Warn and tell people to opt-in (when it detects that it has an unescaped value)
Benefit of v4
URL encoding issue for git dependencies (branch and tag names weren't escaped previously)
Multiple lockfile version writers
Old policy: always latest (maybe two if there we don't feel confident enough to force-update)
This was pre-package.rust-version
Team was smaller
Jacob: Document policy statement on when to update the version
Scott: How often is rust-version set?
Weihang: Have cargo choose to generate different versions, and a flag to choose the version?
eric: Anyone advocating against looking at rust-version? Doesn't seem like it.
Should it look at edition?
eric: Recommend keep it simple, and default to latest.
Eric: Do we want to move forward at all, since it is only fixing one small issue?
No objections. A good test case for the changes we are making.
Jacob: Should it automatically downgrade?
You have a "new" cargo.lock. Then you add a rust-version that is an older version. Should it automatically downgrade the Cargo.lock to the older version?
Weihang: Whenever the lock file needs to be updated, it will automatically downgrade.
The root workspace does not know what the "external" registry is, and thus does not work. This is because the external registry is defined in a .cargo/config.toml in the git repo, but cargo does not read config files from dependencies.
Jacob: Concern about subtle errors or cargo behaving differently in different scenarios
Path and registry config, always start with path?
Cargo always prefers the path, but requires the registry to exist.
Perhaps cargo should only check that the registry exists if the path doesn't exist.
Ed: The infectious nature of the issue should probably be closed, since that is expected behavior. The user will just need to set up the registry configuration.
Trying to load config from the git repo sounds problematic (and dangerous).
Arlo: Define registries in workspace Cargo.toml?
Jacob: config-include could use URLs (like into a git repo). "Terrifying" :D
Jacob: config-include, a company sharing config, a company can specify a checkout of the company-approved configuration.
Eric: Uncomfortable with the PR as is, and deferring the registry check to a later stage sounds pretty difficult.
Josh: In addition to using a global config, projects can have .cargo be a git submodule (to share the registry config).
Josh: Not necessarily wanting to address the generalized problem, but in the error message, have cargo scan for a .cargo with the custom configuration, and tell the user where that is and that Cargo won't use it because it isn't in the top-level crate.
hi-rustin: The error message is pretty terrible, can it be improved?
eric: Thought that it was addressed, where manifests that failed to parse collected error messages, and showed those if it ultimately fails. But maybe it wasn't fixed, will look into it later.
Josh: Rust principle of don't abbreviate, write out full words. "pub" already means "public", so just keep with it.
Except for some of the earlier keywords like fn. In the early days, they were often 3 characters, until it wasn't.
Scott: Might there be confusion of "pub(crate)" within the crate, versus "pub" outside?
Josh: Some crates explicitly re-export their public dependencies.
Wondering if there should be some way to say, be able to depend on the version defined in some dependency.
Ed: This is in a future possibilities.
Jacob: Is this future-compatible with plans of including this in resolution?
Ed: Thinks having a new "resolver" version would be sufficient to migrate.
Action item: make this explicit in the RFC
Josh: When we start warning?
RFC: Start in pre-2024 editions.
Josh: Make that opt-in in older editions.
Older versions will generate an unused field warning for pub.
Ed wants to keep that behavior to just warn while it is unstable.
Older versions will generate an error for public since it is "unstable".
Is this warning suppressed by cap-lints?
Yes
Josh: Crater run, could build a list to potentially tell people ahead of time?
Ed: Transition plans are outlined in the RFC.
Josh: Why not avoid warnings in pre-2024?
Ed: Doesn't want to be too timid in the proposal, and then figure out where to pull back.
Josh: Giving an eager warning if a public dependency has a new semver major version? When running cargo update. "Hey, you probably want to start migrating this forward."
An idea for future-possibilities.
Arlo: Is this in the index?
Ed: It doesn't need to be in the index since it is not being used by the resolver.
Jacob: Thinks it would be useful to have it in for when it is needed in the future.
Is "private by default" and "pre-2024 level is warn" too noisy?
A lot of benefits to "private by default"
Fallback is "lint is rust-2024-compatibility", making it silent but auto-fixed on edition migration
2023-10-17
Note: Jacob starting office hours for pubgrub
ehuss: rustfix repo
eric: Any objections to pulling the trigger on migrating to the cargo repo?
Scott: Might help with tracking issues directly with cargo.
But keeping separate might be good for other users.
Nobody has publish access. Need to fix that first.
Will we migrate the issues?
eric: Intends to migrate most or all of the issues.
Any issues with supporting compiler contributors?
eric: Generally there hasn't been much activity for that, and I think merging in cargo's repo shouldn't be too difficult (and maybe better since it has people active on the cargo repo).
cargo fix for cargo lints, doesn't use rustfix.
Move to crates directory.
Will preserve history.
Would anyone from the rustfix team be interested in helping after it moves?
Probably not. None have been active in years. Manish is around, and is interested in what is happening, but seems unlikely to be actively working on it.
Automatic edits only do best-effort to keep styling, but it is OK for it to change things if necessary. Possibly in the future, cargo fmt can re-normalize the formatting.
This is coming up with automatic adding of workspace.members, which in some cases can reformat how the members list is written.
ed guidelines:
It should preserve the format, including comments, of anything untouched, including outer inline-tables or arrays
When adding new entries, it might not match the indentation style of the existing entries
When removing an entry, trailing comments / whitespace may also be removed
hi-rustin: Should cargo-fix sort the metadata?
Long-term is cargo fmt can fix all the formatting, and cargo fix might leave things kinda messy.
Josh: People may be upset with autoformatters they can't disable. If possible, cargo fix should not disrupt too much.
hi-rustin: How would things like "unused dependencies" get handled?
Arlo: The unused dependency would display a warning, and then use cargo fix to remove it automatically.
Josh: Would there be a desire for cargo fmt to format Cargo.toml in edition 2024, and is the blocker on the style team?
There is a desire to get formatting support, but not a specific timeline set.
If we want it on the style team's schedule, we need to let them know to move up the priority. They need some lead time
Ed: Suggest shooting for the moon while unstable, and then maybe cut back when going for stabilization.
Scott: Unsure if this needs to be done over an edition boundary.
Questions about rustfmt.toml config file affecting Cargo.toml formatting.
Josh: Thinks that formatting should be on an edition boundary.
Scott: Could it just be an option in the config file? Then it wouldn't be tied directly to the edition.
There are style editions, which are in lock-step Rust editions, but they can be controlled independently (one apart) to help with transitioning one then the other (so they aren't mixed together).
Arlo: Has seen changes that were introduced in arbitrary Rust releases.
Josh: let-else was an exception, which is not expected to normally happen.
Scott: What is the process for migrating styling when updating the edition?
Should address that in the edition guide for the process. It will be a multi-step process.
Jacob: Should there be a warning to let you know you are in the middle of a migration?
2023-10-10
Defer close?
Eric didn't get to collecting RFCs as candidates, will try to get to it next week.
Consider if an RFC would need reevaluation if it is left open for a long time.
Race conditions: When PRs are queued in bors, it can include changes that you don't actually wanted in the release.
Arlo: If there are multiple crates being changed, is it possible to only release some of them?
Ed: The tool could potentially separate that out.
Scott: Similar to Renovatebot dashboard?
Ed: Doesn't think so.
Jacob: Maintaining changelogs in multiple files, Python has various tools for doing this, they have a lot of experience of what works and what doesn't.
Ed: Collecting some prior art.
Weihang: Can we release from master?
Eric: The packages are not self-contained due to workspace inheritance. The dependencies get out of sync when the root cargo is published.
Weihang: Any strategy to manage the tags and versions for the crates?
Concerned if a version is released from master/nightly, but unclear if that crate is compatible with a particular Rust release?
unstable features?
Example: A new thing added to cargo-credential, but the cargo side of that hasn't been released.
Arlo: credential could use pre-release versions?
Patching older versions can be difficult with that.
Scott: How hard is it to release credential changes only with the Rust releases?
Eric: We probably aren't planning to do early releases of the credential crates, but we do have other first-party crates that we might want for that (like cargo-metadata, cargo-toml parsing, etc.).
Weihang: Cargo's release process is a bit different that a typical community crate. Could we separate things into two categories (things that release with Rust, and those that we release independently)?
Ed: A problem is that some crates will be in both categories (like cargo-toml parsing).
Weihang: Having them separate can make it easier to have additional people maintain them.
Scott: Thinks something like cargo-toml parsing could reach a stable point where it only needs to be released with the Rust releases.
Scott: Can something like the toml parser have a feature that enables unreleased/unstable things?
Jacob: Or the API has a bool for unstable functionality.
eric: Fortunately not a lot of crates that need support in the short-term (mostly the home crate). I don't expect the credential crates will need early releases anymore.
Today we have
- cargo-platform
- home
- cargo-credential
- cargo-credential-1password
I'm hopeful we'll soon also have
- [an env variable API](https://github.com/rust-lang/cargo/issues/12431)
- [a build scripts API](https://github.com/rust-lang/cargo/issues/12432)
- a (basic) manifests API
Currently, none of these have an MSRV set with the policy being "whatever works" *except* for `cargo-credential` which is set to 1.70 and verified in CI.
The main cost of an MSRV policy will be seen in
- Held back dependencies shared between low MSRV and high MSRV packages
- Delay before we can leverage new features in the language or tooling
Other costs have been lowered. With cargo#12767, we'll be able to support verifying multiple MSRVs in the workspace, using a feature I implemented for `cargo hack`. With RenovateBot, we can implement multiple sliding windows of MSRV policies that auto-update, if desired (cargo#12654).
As these are mostly new crates, we don't have a long history of support to contend with like [libc](https://github.com/rust-lang/libs-team/issues/72) or [time](https://github.com/time-rs/time/discussions/535).
With that said, I would propose we do a sliding N-2 policy (ie supporting 3 latest versions)
Jacob: Bumping every release, even if it is not using new features?
Yes
Decision: Yes, continue with that.
Scott: Should we add edition 2024?
This would help with work on the warning system if #3491 gets merged
eric: Yes.
Documented in features module, just follow the steps.
Scott volunteers to do this.
Scott: When should edition warnings be displayed?
eric: To clarify: Is the question "when should edition warnings be displayed?"
3491 recommends showing the warning when the rust-202X-compatibility lint is enabled.
Scott is working on cargo fix to support the edition migration for Cargo.toml.
When should the warning implementation be done?
What if we don't have the machinery to be able to disable the warning?
eric: A little confused. My expectation is cargo fix --edition would update Cargo.toml without any warning.
eric: When would a warning be displayed?
Showing a generic warn when running cargo on an old edition.
Arlo: Would prefer to not do that
Scott: Would prefer to have it off by default.
eric: Edition diagnostics are never displayed to the user (unless there is an error).
eric will try to review rfc, try to reduce his confusion
eric: Review RFC priorities
Scott: Nested cargo packages are interesting (doesn't have time for review, though). serde_derive nested inside serde is an example.
Ed: Concerns around the index aspect of that. Lots of implications around that. Also helping to mentor that, good potential.
Jacob: Considering something similar. If there was a good way to report errors about things in the index, create a plugin system that allows extending that to allow arbitrary "don't want to use that version". Could potentially have a way to patch using that mechanism.
That could then allow experimentation for different ways of patching things like this RFC proposes.
Useful for larger users (like Amazon) trying to handle patches against dependencies.
Ed: Cautious about a plugin system's impact on the resolver and performance.
Arlo: Also interested in embed Cargo.lock in bins.
Doesn't necessarily need to be in the binary, but could also be a separate file.
Ed: RFC solving a specific use case, but there are some concerns about it if expanded to others (like reproducibility).
Scott: Wasn't there another suggestion like extensible like credential-provider?
Arlo: Lots of different options like how it can be embedded in various ways. Current RFC is too specific. Running into similar issues like compliance.
Ed: Interested in a deeper discussion of the SBOM problem in general.
Different SBOM groups and formats. Cyclone?
Jacob: Are there people who could talk with us? Can try to reach out for it.
Ed: Propose close on Cargo.lock RFC?
Close precise pre-release RFC?
Concern that there is a broader issue pre-release.
Eric: Proposing to discuss these two in the last two.
Eric: What to do about RFCs that don't have anyone on the team to take ownership of it?
Jacob: Could leave a comment to that effect.
Ed: Other teams have done propose deferred.
Jacob: What about tracking and communicating the status of those RFCs, such as postponed status and such?
Repurpose to an official version of cargo release? Or link to the top tools that already exist?
Scott: Could be like credential-process where cargo can defer to third-party executables to do specific actions.
People do want a recommended release tool to orchestrate the release process.
Scott: Can mention there are other tools that can be used, and not pick favorites.
Ed: Could say "here are some examples", and not specifically choosing one.
Jacob: Likes having hooks (like credential-process), such as pre-release, post-release, etc.
Ed: Partially agrees (like a cache process plugin), but concerned about taking it to the extreme where commands behave differently than expected. Thinking about deciding to not have cargo do build orchestration (but support being orchestrated by something else).
Scott: Making cargo more of a library so it can be used as a build orchestration tool.
Scott: cargo clean is the reboot for cargo. It should probably be preferred instead of trying to force through something.
Arlo: Doesn't particularly like the --force
Agree to close
Ed: Would it make sense to record the decisions on what we decided not to do (like in the contributor guide).
Eric: Would be nice to record some of the bigger decisions (the lang team had a similar kind of thoughts with recording what Rust is and isn't). Just don't want to record dozens of small decisions, but more of the big picture things.
Scott: A roadmap could help clarify the vision for the future, where to go long term. Decisions on what to work on now, and what groundwork to lay. Guides decisions on what to do now.
Check-out on process
Try to set bounds on time, if there is more meta discussion to have, note that as something to discuss in the future.
Weihang: Should we add the S-proposed-to-close?
Ed: Could be useful as a filter.
Tag with a comment, if nothing after ten days, just close it.
Example of issue with syn parsing: Error handling could be difficult, and if a syn error happens, cargo could then pass the file to rustc for a better rustc-style error, but that introduces other issues.
HackMD
