Skip to content
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 the bin target #1982

Open
tbu- opened this issue Sep 10, 2015 · 56 comments

Comments

@tbu-
Copy link
Contributor

commented Sep 10, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2015

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

@tbu-

This comment has been minimized.

Copy link
Contributor Author

commented Sep 14, 2015

Sounds great!

@marjakm

This comment has been minimized.

Copy link

commented Dec 7, 2015

Any updates?

@alexbool

This comment has been minimized.

Copy link

commented Dec 16, 2015

+1, would be great to have it

@gyscos

This comment has been minimized.

Copy link

commented Feb 22, 2016

Also consider as possible filters for dependencies:

  • Examples
  • Integration tests
  • Benchmarks

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

@hauleth

This comment has been minimized.

Copy link

commented Mar 25, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2016

@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

This comment has been minimized.

Copy link

commented Aug 3, 2016

Would love to have this.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Aug 5, 2016

@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

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2016

Any progress on this yet?

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Nov 8, 2016

@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

This comment has been minimized.

Copy link

commented Mar 20, 2017

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

This comment has been minimized.

Copy link
Member

commented Mar 20, 2017

@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

This comment has been minimized.

Copy link
Member

commented Mar 22, 2017

Two recent issues where this has cropped up:

@crumblingstatue

This comment has been minimized.

Copy link

commented Mar 22, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2017

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

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Mar 27, 2017

cc #3870 a sample implementation of this.

jcjones added a commit to mozilla/authenticator-rs that referenced this issue May 17, 2017

Fix #16 - Improve logging
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.
@Aldarobot

This comment has been minimized.

Copy link

commented Jan 9, 2019

Is there an RFC for this now?

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@OxyDeadbeef Afraid not. @hwchen How are things with you? I forgot about this thread until now. Are you interested in drafting something up still, with my assistance?

@pwoolcoc

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@alexreg if hwchen isn't interested, I would be

@paulevans

This comment has been minimized.

Copy link

commented Jan 10, 2019

@hwchen

This comment has been minimized.

Copy link

commented Jan 10, 2019

@pwoolcoc

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

Ok, I'm going to try and get a rough draft of an RFC to @alexreg in the next couple days

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@pwoolcoc That's super. I look forward to seeing it. If you have any questions in the meanwhile, tag me here or pop into the #design channel on Rust's Discord server.

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

Is there anywhere I can be a fly on the wall for that so I can understand how that process works?

@paulevans The process of RFC creation? The README on the RFCs repo provides a good overview, which @pwoolcoc will be following I'm sure. Usually the content of such RFC drafts is guided either my one's own ideas and musings or by pre-RFC discussion (over at internals.rust-lang.org). Sometimes they're a collaborative effort. Eventually an RFC PR is opened on the official Rust RFCs repo, when the community and in particular the Rust Lang (Design) team provides feedback on it. Usually the PR author(s) tag people who have been involved in the process, or expressed an interest. In this case we'll also post a link to the draft RFC here, so you can subscribe to that and follow the discussion and process.

@pwoolcoc

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

@alexreg I am still working on this, just taking longer than I expected

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

@pwoolcoc No problem. Here (or on Discord/Zulip) for advice if you need it, otherwise just ping me when you have a draft ready.

@Walther

This comment has been minimized.

Copy link

commented Jan 27, 2019

Excited Rust beginner here, also eager to try and help in any way i can. Writing a side project & bumped into this issue. I'm on both of the Discords with same username, feel free to ping! ❤️

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2019

@Walther We'll post a link to the RFC (draft) PR here when it's ready, which will hopefully be soon. :-)

@dmarcuse

This comment has been minimized.

Copy link

commented Mar 21, 2019

Has any progress been made with the RFC? I'd be willing to try writing one if it's been dropped again.

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2019

@dmarcuse It seems that it has been dropped yes. If you'd be interested in taking it up, then great. I'm happy to provide advice or help review it.

@dmarcuse

This comment has been minimized.

Copy link

commented Mar 21, 2019

I'll start working on it this weekend and keep you updated!

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2019

Super. You can contact me here, or on Discord/Zulip if you like.

@dmarcuse

This comment has been minimized.

Copy link

commented Mar 25, 2019

@alexreg I started drafting the RFC and sent you a friend request on Discord, could you accept it so I could ask some questions?

@alexreg

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

@dmarcuse Okay thanks! Accepted now. (I think you can PM me regardless, but yeah, ask away...)

@djc

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

@dmarcuse @alexreg have you made any progress since your last comments here?

@alexreg

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

@djc Yep, @dmarcuse has begun a draft, and I've looked at a bit. Will review some more today.

@dmarcuse

This comment has been minimized.

Copy link

commented May 9, 2019

@djc I have been (very slowly) working on a draft available here - feedback or contributions would be appreciated!

@djc

This comment has been minimized.

Copy link
Contributor

commented May 12, 2019

@dmarcuse what you have so far looks good! For drawbacks and alternatives, it would be probably be useful to dig into what require_features currently does and how it would interact with your proposed feature. Otherwise this so far seems like a fairly straightforward feature and a mostly natural extension to what we already have, so there's probably not a lot of prior art and future possibilities to talk about.

My advice would be not to try to polish it all to perfection before you submit it, just write up whatever's in your mind and push it, then the community can help you with more feedback.

@dmarcuse

This comment has been minimized.

Copy link

commented May 12, 2019

Thanks for the tips @djc! I'm going to try to work on it more later today.

@alexreg

This comment has been minimized.

Copy link
Contributor

commented May 12, 2019

Yes, we'll specifically get Alex Crichton's feedback on it once we have it in a decent state. :-)

phil-opp added a commit to rust-osdev/bootimage that referenced this issue Jul 18, 2019

If the bootloader has a feature named `binary`, enable it
This allows the bootloader to define dependencies that only apply to the main.rs (not the lib.rs), in order to reduce compile times. See rust-lang/cargo#1982 (comment) for more information.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.