Properly handle hybrid packages

[charlesrocket]

Problem

There is no way to properly maintain a hybrid package (bin+lib). If a developer wants to deploy such package, he/she is forced to pollute the platform with each crate in this package's workspace [1] since this is the only way to separate bin and lib dependencies. Using features sounds like a workaround since one should be able to build a binary without telling compiler about the target twice.

Proposed Solution

Utilize attributes/etc to group/tag dependencies for binary or library usage. the compiler/cargo must know that when binary target is built there is no need to touch library dependencies.

Notes

1. If you publish the crates in the workspace to crates.io, each crate in the workspace will need to be published separately. https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html

[epage]

Is this a duplicate of #1982?

[kpreid]

While not strictly necessary, this seems like it would be a well-fitting feature — a [bin-dependencies] section analogous to [dev-dependencies] but which applies to bin targets.

Might be a duplicate of #1982 but the most recent discussion there seems to propose enabling features in the library from the binary, which would work for this (and has its own use cases) but is a more indirect way of specifying what you want, which has two disadvantages:

• within a given workspace it would imply recompiling the library with different features depending on whether you build the bin (even though the library code is unaffected)
• the library's list of features and deps (as seen on crates.io and docs.rs) would be polluted with entries only relevant to bins, which might confuse users as to what the library's scope or requirements are.

[epage]

the library's list of features and deps (as seen on crates.io and docs.rs) would be polluted with entries only relevant to bins, which might confuse users as to what the library's scope or requirements are.

docs.rs has a convention to hide _ prefixed features. #10794 is the issue for supporting this in cargo add. #10882 is for making an official way for hidden or private dependencies.

[charlesrocket]

@epage Oh seems like this is the same topic indeed. @kpreid I was thinking about something that would work both ways, ie just declaring required dependencies for each target. Frontend could just output one list, with B/L tags next to each dependency, like its happening right now with features.

[charlesrocket]

@kpreid something like:

[dependencies]
clap = { scope = ["bin"], version = "*", features = ["std"], default-features = false } 
png = { scope = ["bin", "lib"], version = "*" }

[epage]

Going to go ahead and close this as the topic is the same. If there are dissenting opinions or alternative proposals, let's have that all in one place rather than spread across issues.

[charlesrocket]

@epage I am blasted away, this is unresolved since 2015
ouch

[epage]

Yes, understandable. We see that response to a lot of our issues. The scope of cargo makes it so there are a lot of high interest areas that make it hard to get to all of them. For example, this isn't a priority to me as I've found I prefer to have separate crates for bin/lib. A lot of work ends up being user-driven.

Lately, the cargo team has also been even more limited, see https://blog.rust-lang.org/inside-rust/2022/03/31/cargo-team-changes.html.

[charlesrocket]

I understand teams are busy, theres no question here