Cargo team: planning areas

[nrc]

These are the 'big things' that might be happening in the near-ish future for Cargo, which might be on the 2019 roadmap, and which we should discuss in small 'focus groups' over the next few months. Please add more things and any meta-thoughts, but lets leave discussion of the specifics for later.

• - Architecture
• - Downloads
• - Manifest changes
• - Workflow
• - Project knowledge

• rustup integration
• sysroot/extern crate stuff
• build system integration (and high level refactoring)
• templates/generate
• caching/distributing binaries
• pub/priv deps
• custom registries (is this just stabilisation?)
• std-aware/Xargo
• cargo add, etc.
• specifying tools versions, toolchain versions
• profiles (does this overlap enough with build system integration that they should be merged?)
• metabuild (native deps for sys crates; I'm not really sure what this is)

[dwijnand]

cargo repl would be nice (possibly based on https://github.com/google/evcxr/tree/master/evcxr_repl?)

[dwijnand]

Other 'big things' which might be worth undertaking:

• Allow dependencies that only apply to specific cargo targets (bin, example, etc.) cargo#1982 ("Allow dependencies that only apply to the bin target"), 82 👍s (top 👍'd)
• cargo build --dependencies-only cargo#2644 ("cargo build --dependencies-only"), 50 👍s (3rd top 👍'd)
• Add an "airplane" flag to Cargo, altering it's dependency resolution behavior cargo#4686 ("airplane mode"), most ❤️'d issue

(2nd top 👍'd is the sysroot/xargo ticket, already mentioned)

[ehuss]

You can look through https://doc.rust-lang.org/nightly/cargo/reference/unstable.html and review the status of all unstable features.

I would say "rename-dependencies" is the closest to stabilization (I don't know of any outstanding issues). We may want to prioritize it, since in might help with 2018 usage.

custom registries (is this just stabilisation?)

There seems to be a lot of unresolved issues in the tracking issue.

metabuild (native deps for sys crates; I'm not really sure what this is)

This is just an easier way to write a build script (using metadata in Cargo.toml instead of writing a Rust program), and can be used for a wide range of things (not just sys crate building). It's low priority until we can find people to play with it.

I have been researching "decoupled features" where Cargo features can be more granular. It sounds like @alexcrichton wants to go with a conservative route to only decouple cross-compiled artifacts. I think there is significant interest in a more pervasive split where normal/build/dev/target-cfg can all receive different features (for example, a feature needed for build is not forced upon your main crate). It's one of the most requested enhancements. I think it would be good to have progress on this...somehow.

[ehuss]

Another major area that I think needs attention is reducing disk space usage. There are multiple points to this: automatically cleaning target, improvements to manual cargo clean, and dealing with stale cache files in the registry directory. There are a fair number of issues filed for this, and I see it come up periodically on forums and other places (like llogiq's recent blog post). I have some ideas for some short-term solutions for updating toolchains which I'll post soon. However, I'm not sure if making incremental improvements is a good idea vs. making major changes.

[nrc]

Categorization

I'm not really happy with the names, but the main point is the groupings

• architecture
  • rustup integration
  • build system integration (and high level refactoring and API)
  • custom profiles
  • build deps only (use case: Docker, CI)
• download-ish stuff
  • caching/distributing binaries
  • custom registries (is this just stabilisation?)
  • offline mode (remaining work - possible global cache)
• manifest changes
  • pub/priv deps
  • specifying tools versions, toolchain versions
  • per-target deps
  • more fine-grained feature flags
• workflow
  • templates/generate
  • cargo add, etc.
  • metabuild (https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#metabuild decl build scripts to help building native deps)
• project knowledge stuff
  • std-aware/Xargo
  • sysroot/extern crate stuff
• maintenance
  • triage unstable features (https://doc.rust-lang.org/nightly/cargo/reference/unstable.html)
  • reduce disk space use
  • ergonomics of existing workflows

[nrc]

The kind of things we need to work out for each feature are:

• use cases
• why should this be p-high?
  • urgency
  • importance
• current status
• how much work to complete
• surface area
  • CLI
  • manifest changes
• what could this subsume?
• how might this interact with other 'big' proposals?
• a very rough plan for implementation
• is anyone signed up/keen to do the work?
• alternatives?

[withoutboats]

custom registries (is this just stabilisation?)

There's one change I wanted to put in but I've never gotten around to getting green in CI. rust-lang/cargo#5915. Otherwise I think it needs a review to see if everything else is spic & span, then a stabilization PR.

[nrc]

We should also consider what community commands we want to bring in, e.g., cargo tree, cargo add (cc #14), cargo watch, etc.

[nrc]

Notes to self:

• pipelining builds
• security issues (work with secure code WG, crates.io team)