Allow dependencies that only apply to specific cargo targets (bin, example, etc.)

[tbu-]

Use case: I have a library that also produces an executable. The executable needs env_logger in order to be able to log, the library shouldn't carry that dependency though, as it pulls in all sorts of crates (e.g. regex (?)).

[pwoolcoc]

@tbu- I have a branch with this mostly working, I'm trying to get it cleaned up and committed "soon"

[tbu-]

Sounds great!

[marjakm]

Any updates?

[alexbool]

+1, would be great to have it

[gyscos]

Also consider as possible filters for dependencies:

• Examples
• Integration tests
• Benchmarks

Also, should it be per-binary (when multiple are provided)?

[hauleth]

@gyscos all of that can fall into dev-dependencies bucket. I see no reason for giving ability to set dependency only for benchmarks or something.

[azerupi]

@alexcrichton is this a desired feature? Would a PR proposing this get merged?

My personal opinion is that it would be useful for libraries exposing a little cli alongside of a lib (e.g. pulldown-cmark) because it would allow them to, for example, pull in an argument parser (e.g. Clap) without imposing that dependency on all the library users and without the need to create a separate crate for the small binary.

Also, should it be per-binary (when multiple are provided)?

What is your opinion on this and how should it be represented in Cargo.toml?

[fulmicoton]

Would love to have this.

[alexcrichton]

@azerupi yeah I suspect Cargo will end up with something like this eventually, it's certainly a well motivated feature! I wouldn't got he route of dependencies-per-binary yet, though, as we don't similarly also have things like dependencies-per-example or dependencies-per-test

[alexreg]

Any progress on this yet?

[alexcrichton]

@alexreg unfortunately, no

This would likely require an RFC as it's an extension to Cargo.toml (e.g. a whole new section for dependencies)

[rminderhoud]

Hello, while this is being worked on is there a temporary "best practices" for handling this kind of project structure (root library crate -> member bin with additional dependencies)? Right now, is the only way to avoid polluting the library dependencies with the binary dependencies is to have each binary be a separate (non-workspaced) crate?

[alexcrichton]

@rminderhoud in the meantime the "best solution" (it's not really that great, but it works) is to split up into separate Cargo projects which can each have their own set of dependencies.

[steveklabnik]

Two recent issues where this has cropped up:

• Semver binary version. dtolnay/semver#101
• Split out binary and lib build pulldown-cmark/pulldown-cmark#55 and Remove unwanted conditional compilation pulldown-cmark/pulldown-cmark#56

[crumblingstatue]

The most general solution would be to allow optional dependencies for every bin target. TOML makes this relatively easy to express:

[[bin]]
name = "foo"

[bin.dependencies]
clap = "1"
term = "0.5"

[[bin]]
name = "bar"

[bin.dependencies.cooldep]
version = "2.0"
default-features = false
features = ["foo"]

In the future, this general concept could also be expanded to examples/tests/etc., if deemed appropriate.

[alexreg]

I agree, the syntax & semantics proposed by @crumblingstatue look pretty sensible.

[alexcrichton]

cc #3870 a sample implementation of this.

[Mart-Bogdan]

@hauleth

all of that can fall into dev-dependencies bucket. I see no reason for giving ability to set dependency only for benchmarks or something.

No, there is benefit -- reduce build time of tests, for example.
And reduce bloat and work on linker to strip uneded code. If bin would require test deps, we would need to buld all tests related stuff for binary.

[segevfiner]

I got hit by this when developing segevfiner/keepawake-rs (segevfiner/keepawake-rs#3), and I'm not sure how to restructure/split my crate in the mean time to avoid this issue. In terms of which part of the crate I should split into a sub-directory in a Cargo workspace and how to handle all the project metadata, README.md and so on, cause I'll have to write two, and/or how to correctly publish in such a configuration...

I tried the users forum but got no answer there as well https://users.rust-lang.org/t/whats-the-convention-for-handling-a-hybrid-library-and-binary-crates-dependencies/84174

[pksunkara]

New RFC has been proposed: rust-lang/rfcs#3374

[detly]

For the specific use-case of binaries that exist to help with integration tests, I've made a test-binary crate that might help. It's admittedly pretty niche, but it's why I'm watching this issue, so maybe it'll prove useful to others too.

[tae-soo-kim]

@tbu- I have a branch with this mostly working, I'm trying to get it cleaned up and committed "soon"

"soon"?

[wiiznokes]

New RFC has been proposed: rust-lang/rfcs#3374

This is not the same feature of this issue

[mccolljr]

I hate to bump a stale thread, but I was curious about this today and google led me here. Is this a "dead" effort, or is there some blocker to implementing this that is not mentioned here?

[lure23]

I would use such feature to enable defmt feature (dependency) for all examples, while keeping it an opt-in for the lib itself.