Default-install-features: yet another Pre-RFC for erganomic lib+bin crates

Prior Art: RFC 3374

Problem: lib+bin crates typically want to exclude the dependencies used for command-line argument parsing when being built in library-only mode. currently this is solved using feature flags, but this either requires everyone installing your package to use cargo install --features cli or everyone using your package as a library to specify default-features = false.

Solution: add a new field, package.default-install-features, for features that should be added to the list of default features when using cargo install.


  1. still requires a fair bit of boilerplate with required-features and such.
  2. only works for cargo install, doing cargo test --bin will still require listing the binaries.


  1. recommend even trivial crates to use the workspace layout
  2. make argument parsing part of the lib half, like the cargo crate
  3. do nothing, and continue to mildly annoy anyone who tries to use a lib+bin crate
1 Like

speaking generally

For more background on the general problem, see This Development-cycle in Cargo: 1.77 | Inside Rust Blog

That would be nice to have.

Getting an error about missing required-features feels almost like the tool was spiteful. It gets a clear instruction, it knows exactly what the problem is, it knows the solution, but just won't do it.


Solution: cargo-xtask

Although I have no knowledge about that tool, but I had seen lots of people use this word in my thread.

I'm really curious why they do not tell you this tool.

cargo xtask isn't even a piece of software, it's a useful hack that uses command aliases to run a package.

and notably, it only works if you're inside the directory of the project, meaning yo have to do a git clone.

generally speaking, it's almost entirely unrelated, since it is for developers (of a given project), not for users of a project.