This appears to contradict the answer to the previous question. Is it or is it not allowed to do this? If not, doesn't this break backwards compat a bit harshly?

s/their/there/

s/extend/extent/

s/dependencies/dependency/

s/last/list/

Are there concrete usecases where these annotations would help? Those would be worth mentioning here (primarily to pitch this RFC to unconvinced readers)

At least when I started writing Rust, I upgraded dependencies in a PATCH release without thinking about the implications for reexported APIs. This change could make crate authors think about this from the start. The last bulletpoint in "Unresolved Question" also hints at this.

• You already hint at libcore and libstd, but to me this part is missing justification for why we should allow normal crate authors to disable this warning. An example where this becomes necessary might help.
• At https://github.com/rust-lang/rfcs/pull/1977/files#diff-396833e435181d84da75db4b1f53ef8dR137 you list a few cases where one might think it'd be fine to use this. For example when leaking impls of external traits. Which usecases do we encourage?

I rather not go into too much detail about this as this is a big unknown. I think it's largely irrelevant for this RFC anyways because we initially start out with just compiler warnings. Where to go from there will be seen by how much damage this does.

Not a review, but random thought: You might have a public dependency that changes its major version but doesn't change the part of the API you reexport, or perhaps it just bumps its major version too aggressively.

This is still a breaking change in your library.

Suppose you and another crate foo both depend on the same version of bar, and both re-export bar::Bar. I depend on both you and foo, and pass a Bar I got from you to foo in my code. This works fine, because your Bar is the same type as foo's Bar.

bar releases a breaking change, which does nothing to the definition of Bar. You update to that major version, but don't do a breaking change because you believe nothing in your code has changed.

However, now its impossible for cargo to unify your dependency on bar with foo's dependency on bar, because they're different major versions. This means that you::Bar and foo::Bar are no longer the same type. If I upgrade my dependency on you, I will get a breakage, so you have made a breaking change.

Good point, I completely overlooked that aspect. I have a few other concerns/questions about this feature (that don't really affect this PR), but let's cut this discussion short to not clutter this PR.

What if you relax the range on bar to include the new version rather than just bumping to only using the latest version. What kind of bump does that mandate?

ISTR seeing that it would be a major change due to cargo always choosing at the high end of the version constraint range. Would it be worth an RFC to cargo to have it see dependencies of >= 1.1, < 3 and ^1 in different crates to, instead of deciding on two copies, one of version 2.x and another of, say, 1.5, instead see that 1.5 satisfies both and ignore the 2.x version?

@mathstuf yeah this is what I thought about as well but consider off-topic for this RFC

This paragraph has confusing wording, at least to me. To reiterate the point of this example, you could say that "public" is a property of the dependency relation (the edge in the dependency graph) and not of the crate or the package (the node).

s/bumb/bump/

s/depenencies/dependencies/

We also need to be able to express a private dependency which is locked with another dep's public dependency, see my running a -> c; a ->b; b -> c example from above.

@Ericson2314 is this really necessary? Why can you not just have a pin on the major version? eg: url = { version = "1", public = true }.

@mitsuhiko actually it might not be, but we should make not of this in the semantics: just as your public deps must be unique version per name, so your private dependencies and their public dependencies must be unique version per name.

I think this is one place where @bbatha's concern (link-only-once) diverges from what's described by (and very useful for) this RFC, and the two probably need handled distinctly.

In particular, in the absence of link-only-once dependencies, a private dependency hides all transitive dependencies behind it - and this is hugely useful in some cases.

However, link-only-once crates must not be hidden in this manner.

As a result, I think these might be better served by orthogonal mechanisms.

Yeah. I am not entirely sure how to best deal with link only dependencies. They are definitely iffy and out of the scope as far as I'm concerned. I will add a section about those to the RFC.

Agree that it's out of scope. Simply requiring that all link-once deps be reachable through chains of public dependencies is sound, but way overly restrictive.

How about cratename = { from_dependencies = true } (or similar)? You're relying on deps to not break API with their deps being bumped, but that's true anyways already.

I don't understand why from_dependencies is a better name than public, or how the version could be inferred. Could you give an example?

It'd be a replacement for version = "…" and an indication that cargo should figure out the version based on public dependencies of dependencies instead of trying to give a constraint directly. Basically "I'm fine with whatever my dependencies need because that's how I use this crate".

I see, as far as I understand this could be a different RFC independent from this one though.

I think people should just pin less strictly instead. It's fine to just pin for 1 for instance.

But if I use a crate only because dependencies use it, why not have a way to say "I use it only because dependencies make me use it; let them tell me what version I need"?

In any case, probably a topic for a separate RFC.

But if I use a crate only because dependencies use it

If you only use it because dependencies use it and it's not part of their APIs the dependency is invisible to you. If it's a visible (public) dependency then the version of the dependency is relevant to you.

I don't really like this language. If you depend on items from a dependency (e.g. types) even if you don't reexport them, you still need a public dep. Also----and this is crucial---if you don't reexport anything, it's not a breaking change to change your public deps if you're own interface doesn't change.

Consider a situation where a depends (privately or publicly) on b which publicly depends on c. To use any items from b with interfaces relying on c, a should also need to depend on c (and constrain that dep to be unified with b's). But now the extra dep of a on c forces the "effective interface: of b with given c to not break. Conversely, if a doesn't do that, then we know b's use of c is irrelevant so the relevant parts of b also won't break.

This is an instance of the general principle that the version of a crate is like a fallback / catchall that describes the remnants of the interface not already accounted for in the crate metadata, and constrainable with a dependency. Public deps are accounted for and can be constrained downstream, and thus need not cause interface breakage in and of themselves.

This may sounds like needlessly fancy reasoning, but this is actually really important practically. Breaking changes already are difficult growing pain with large ecosystems, and would become impossibly so if on every upstream breaking change, all publicly depending downstream was forced to issue their own breaking change even if all they did is bump a dependency. Conversely, tiny breaking changes are far easier to deal with if every publicly depending downstream libraries that aren't affected (i.e. most) just need to make a new release with a relaxed upper bound on their public dep).

If you depend on items from a dependency (e.g. types) even if you don't reexport them, you still need a public dep.

Can you clarify what you mean by that? If you do not re-export them there is no need for a dependency to be public.

Perhaps we are using "re-export" differently? To me, reexport means you include the *definition" in your interface, i.e. with a pub use, as opposely merely using the dependency's items. Reexporting is bad thing to do because then the public dep really does become part of your API in ways downstream may not control --- merely bumping a version bound over a breaking change may indeed be a breaking change.

Correct. If you accept a type from a crate as parameter it means it's re-exported in your API.

Uh I am not sure which you are agreeing with?

Maybe I'm just to dumb to understand the comment but I do not quite follow what the difference here would be. Is the idea that if you use a subset of b that does not c you do not want a public dependency to c? That should be covered anyways.

@mitsuhiko With the terminology change, the only remaining issue is the sentence: "Effectively the idea is that if your own library bumps a public dependency it means that it's a breaking change of your own crate."

I realize now this sentence is doesn't actually effect what this RFC specifies, so as far as the detailed design goes we're all good---feel free to just cut that sentance and ignore the rest of this post :).

But for the record, actually a changing of a dep should never be a breaking change. In the private dep case, downstream cannot tell at all, so we're good. In the public dep case, the solver will simply not use the new crate if the public dep cannot be unified with other public deps.

I wrote before

This is an instance of the general principle that the version of a crate is like a fallback / catchall that describes the remnants of the interface not already accounted for in the crate metadata, and constrainable with a dependency.

I think I have a better way of describing things. The general maxim for compat is "if I publish this crate, in all solutions where this this crate could be substituted for another, things must work in both case". If there is a solution where the substitution breaks, we could try to fix that case, or we could try to rule it out.

Since public deps may be exposed but also must exist once, any bounds adjustment is OK because the version unification would rule out laxer bounds switching to another version the other crates in the plan cannot cope with.

Mathematically, one can view a crate wrt compatability as Map<PubDeps, Map<Name, Item> (maps are partial functions). Just as adding definitions to a crate preserves compatibility, so relaxing bounds does too---both just extend domains of the partial functions. Whereas removing definitions does not preserves compatibility, tightening bounds is fine because solver-time failures are fine (the solver just moves on) whereas build-time errors aren't.

Hmm @alexcrichton in #1977 (comment) you wrote

When libc reaches 1.0 then many crates will need to bump their major version as libc is a public dependency.

But per this thread it would only be a minor bump. Using this side-thread as it's not really a core part of the RFC but do want to get this clarified.

It's possible we'd need to tweak some things like method resolution for what I said to actually be true. (e.g. do the inherent methods of a reexported type "vagabound" with the type and are usuable via the export?)

I believe Alex meant all the crates with a public dependency (direct or transitive) on libc would need a major version bump when libc goes 1.0, but all the crates with a private dependency (direct or transitive) on libc would not. That's why the next sentence of that comment is:

This RFC will allow us to precisely identify what set of crates need to be bumped, transitively!

Where I believe "need to be bumped" refers only to major version bumps.

Right, I'm trying to argue that, absent reexports (as opposed to mere exposing of departure) changing dependencies in any way is not a breaking change because every plan the build could go wrong the solver will disallow anyways.

I think you're missing something - specifically, I think this may require changes to the index format in order to allow Cargo to make dependency-resolution decisions based on whether dependencies are public.

Without changes to the index, either Cargo will still need to perform conservative "everything is public" resolution (and the situation does not actually improve), or it may perform "optimistic" resolution (as if everything is private) and decide on a resolution that it cannot tell is invalid until after it's downloaded the crate archives (which is wasteful, and offers no clean recovery path).

@eternaleye why would cargo have to assume a public dependency?

@mitsuhiko this is about whether the solver guess solutions which it then checks against dependency privacy, or whether it has access to privacy while solving---the latter is probably far more efficient as partial solutions can be ruled out earlier.

@Ericson2314 cargo knows what dependencies are public from the definition in the Cargo.toml. The only thing the #[allow(...)] does is silence the warning (later error). I don't believe it needs to impact the dependency resolution algorithm but I might be missing something here.

@mitsuhiko: The problem here is with the privacy/publicity of transitive dependencies. Imagine the following dependency graph:

• A
  • B
    • D
    • E
  • C
    • E

All dependencies are public, and furthermore let us presume that these "E" dependencies are ones that, if one of them were private, would fall into resolutions that "previously [were] prevented from compiling by restrictions in cargo."

I clone A, and run cargo build. Cargo's dependency resolution does not have access to the Cargo.toml for anything other than A. For everything else, it accesses the index. As a result, in order to know whether B and C depend on E privately or publicly, the index must carry this information.

If it does not, Cargo has a few options:

1. Presume they are all public, and reject the resolution. No improvement over today.
2. Presume they are all public, and if the resolution would be rejected, fetch all potentially eligible crates in order to re-perform resolution using their Cargo.toml files. Incredibly network-intensive, may fail anyway, significant new logic.
3. Presume they are all private, begin fetching the selected crates (which may have version skews that are not permissible!), and then discover then that the resolution is irresolvable. Network-intensive, offers no usable error handling path where some versions of B (or C) make E private and others make E public.

@eternaleye in case you are referring to the crates.io index, yes that information (public true/false) would be contained in the "deps" section.

I for some reason thought you meant that #[allow(external_private_dependency)] needs to be reflected in the index.