Figure out interaction with public/private dependencies.

[ehuss]

Currently the public/private status is hard-coded to "public". Need to think of how to handle this properly.

[Ericson2314]

See https://github.com/rust-lang/wg-cargo-std-aware/issues/12. Deps of crates.io from std-lib crates should probably be private.

[ehuss]

Ah, to be clear, I mean explicitly from user crate to std or core and other user-visible std libs. The internal/transitive dependencies within the standard library will use whatever rules they declare (which is none, which currently defaults to private).

Presumably in the future there will be an explicit dependency listed in Cargo.toml to std. When cargo starts using that, it will likely inherit the visibility from that definition, which defaults to private, which is probably not a good choice.

pub/priv may gain a 3rd "unspecified" form, but we haven't decided on how that will ultimately work.

And if a dependent crate doesn't have an explicit dependency to the standard library, it may need special consideration. It probably should revert to the default, which due to the way it is implemented will require special handling.

Or maybe it should always be public with no means to change it.

I imagine if/when we ever turn on pub/priv, the standard library will need to correctly declare its dependencies as well.

[Ericson2314]

I imagine if it's explicit, it should work like any other explicit dep, and if it is implicit, it should be public.

I would say this is more motivation that neither public or private should be the default, not that we need a special case for some explicit deps.

[alexcrichton]

AFAIK public/private only affects version resolution and warnings, right? There's no version resolution with user crates against libstd (there's always only one libstd) and there's no need to print warnings about libstd dependencies, so it may be that we can just ignore public/private for libstd?

[ehuss]

Yea, I think that's right and that's why I currently hard-coded it to be public = true.

It may be there's nothing to do here (other than remove my TODO comment in the code), and make sure it doesn't break in the future.

I'm also thinking of what happens in the future if someone says:

[dependencies]
std = {public = false, …}

we may want to reject that?

[Ericson2314]

Proc macros may use a different version of std when bootstrapping. Please let's try to solve this in the most std-agnostic way possible.

[alexcrichton]

we may want to reject that?

Agreed yeah, with w/e syntax we invent for depending on std/core/etc directly we'll want to be as conservative as possible and reject most keys to explicilty add support for them later.