- move fmt to rust-lang (or nursery?)
- current thinking about wiki (brson)
- liblibc and winapi version bumps (aturon/acrichto)
- pattern matching update (nmatsakis)
- multirust - multirust-rs, cargo integration
- Proposed to move rustfmt into the rust-lang organization
- Everyone in favor of moving into one of the orgs (rust-lang or rust-lang-nursery)
- Recapped rationale around nursery for the libs team
- acrichto: Don't feel that it's quite up to par to call it "rust-lang"; we can't yet run it on entire rust repo
- multirust is another example nursery candidate
- all in favor moving to nusery, want to make this an official part of tools team; will need RFC to promote
- should make this an official part of tools team process
- Recap of wiki concerns: nice to have a place to store documentation/info that can grow organically, talk about compiler development, policies, etc.
- Downside of organic growth is you can end up with a disorganized sprawl, with lots of stale information.
- Questions: is there a gap here in organic growth/place to put this documentation? What should the scope be?
- wycats: Very concerned about staleness; have had lots of bad experiences around this in the past
- wycats: How do we avoid the downsides?
- nmatsakis: If not a wiki, where else would this info live?
- steveklabnik: I always wanted this to be "real" docs, but it tended to get sucked into the wiki
- brson: Don't want to get hung up on the term "wiki". These docs need to live somewhere. Steve is worried about quality, but it may be so important to have some docs that even low quality is better than nothing.
- wycats: My worry is about calling it a wiki and having no real access control; end up with a dumping ground
- brson: Nobody wants to open this up with no oversight/reviewing. Just want a place with a lower bar than the current web site (Some discussion about strawman ideas)
- Proposal to be posted to internals forum
-
Some key crates underwent a major version bump, with major breakage across the ecosystem
-
Some of the problems:
-
*dependencies, which are going to be outlawed soon -
cannot straddle major version boundaries (e.g. 0.1 - 0.2), because of resolution issues
-
winapi crates had an annotation for linking to a native library, and cargo doesn't allow multiple such annotations for a given native lib, so resolutions that keep both 0.1 and 0.2 would fail
-
-
wycats: Those are the proximate causes. But note that the proposed solutions to these problems somewhat contradict each other. TL;DR, I think we were overeager in allowing duplication of dependencies -- want to discuss this more in the upcoming work week.
-
no immediate action items: the current round of breakage is being mitigated, and has brought some awareness about dep story
-
Will set up discussions at the work week, including with cargo consumers
-
nmatsakis: Do any of these ideas lead to breaking changes?
-
wycats: Possibly, depending on how you think about it -- it wouldn't change existing lockfiles, but could affect ability to resolve when you add new dependencies. Will need to think carefully about the tradeoffs here.
https://internals.rust-lang.org/t/how-to-handle-pattern-matching-on-constants/2846/44 <--
- 14 broken crates on cargo
- Plan is to write RFC proposing deprecation strategy, given these numbers
-
What's the plan with multirust-rs?
-
Want to use it to unify Unix/Windows installation/rustup/rust installer
-
Laid out a workflow with diggsey
-
Want to rebrand unified tool as "rustup" (separate from cargo)
-
Put everything in cargo/bin, no more global installs
-
These are all rust libs, so you can develop e.g. visual studio plugins easily
-
Also a great place to manage NDKs
design: https://public.etherpad-mozilla.org/p/rustup-new-experience
- Some open questions around integration with Cargo, e.g. asking for a specific toolchain