-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow dependencies that only apply to specific cargo targets (bin, example, etc.) #1982
Comments
@tbu- I have a branch with this mostly working, I'm trying to get it cleaned up and committed "soon" |
Sounds great! |
Any updates? |
+1, would be great to have it |
Also consider as possible filters for dependencies:
Also, should it be per-binary (when multiple are provided)? |
@gyscos all of that can fall into |
@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.
What is your opinion on this and how should it be represented in |
Would love to have this. |
@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 |
Any progress on this yet? |
@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) |
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? |
@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. |
Two recent issues where this has cropped up: |
The most general solution would be to allow optional dependencies for every [[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. |
I agree, the syntax & semantics proposed by @crumblingstatue look pretty sensible. |
cc #3870 a sample implementation of this. |
Pull in the log crate and move all the OSX println statements to be at appropriate log levels. This also pulls in `env_logger`, an implementation of a logger, that obeys an environment variable RUST_LOG. I added some notes to README.md as to how to use it. Optimally, we don't need `env_logger` except for tests and the binary, but we can't eliminate it from the library form until [this PR for cargo completes](rust-lang/cargo#1982), so we might need to refactor it out of main.rs when this becomes a Gecko lib. But maybe not? Anyway, it's easy to change down the line.
No, there is benefit -- reduce build time of tests, for example. |
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 |
New RFC has been proposed: rust-lang/rfcs#3374 |
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. |
"soon"? |
This is not the same feature of this issue |
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? |
no point in requiring csv when using diameter as a library there is seemingly not a better way to do this yet: rust-lang/cargo#1982
I would use such feature to enable |
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 (?)).The text was updated successfully, but these errors were encountered: