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

Rust compiler versions and private dependencies #1

Open
mathstuf opened this issue Sep 20, 2018 · 3 comments
Open

Rust compiler versions and private dependencies #1

mathstuf opened this issue Sep 20, 2018 · 3 comments

Comments

@mathstuf
Copy link

The document currently states that private dependencies aren't discussed, but a note for the future is that the rustc minimum dependency is "never private" and cannot be hidden. The same is also true for any #[link] library since those must be unique.

@teiesti
Copy link
Owner

teiesti commented Sep 21, 2018

I think, You misunderstood my definition of the terms "public" and "private". A dependency is private if the the crate does not reexports a feature (like some API) of the dependency. Private does not mean that the dependency is somehow hidden from or invisible to the user.

Therefore, rustc is a private dependency as long as You don't reexport something from the standard library. (You can use the standard library but you cannot make it available to others.)

Am I correctly understanding Your issue?

By the way: Thank You for actually being the first one going into discussion with me about my paper!

@mathstuf
Copy link
Author

But the compiler is special. If I have a crate that only privately depends on itertools and itertools bumps its minimum Rust version to 1.30, how is one to go about acting as if that private dependency isn't visible from my crate?

A similar issue exists for things like openssl-sys. If one project has a private dependency on it and they bump it, another dependency of mine which uses openssl-sys must agree on the version, otherwise the compile will fail.

Issue references:

@teiesti
Copy link
Owner

teiesti commented Sep 21, 2018

Oh yes... I think You're right!

rustc and native dependencies always need to be public for the reasons You've mentioned. (I think, I actually thought about this when I wrote the text two month ago -- and forgot... Sorry!)

I think, I've mentioned the private dependencies because the restrictions I've concluded do not apply in general when a dependency is private (or not somehow special like rustc). Therefore, it makes sense to differentiate between private and public dependencies in order to have more versions that are compatible to each other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants