-
Notifications
You must be signed in to change notification settings - Fork 984
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
*: Remove default features from all crates #2918
Conversation
This makes search and replace operations work better.
This crate does not have any default features.
Adds a CI check that ensures we specify the correct features for each example.
This gets rid of the cool but complicated CI check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this.
As mentioned elsewhere, I am in favor of this change.
Given that this is a large breaking change for users, is there anyone objecting to this change?
@@ -46,7 +46,7 @@ ring = { version = "0.16.9", features = ["alloc", "std"], default-features = fal | |||
async-std = { version = "1.6.2", features = ["attributes"] } | |||
base64 = "0.13.0" | |||
criterion = "0.4" | |||
libp2p = { path = "../", default-features = false, features = ["mplex", "noise"] } | |||
libp2p = { path = "..", features = ["full"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Say I want to run the libp2p-core
unit tests locally, wouldn't it be nicer to only compile the libp2p
features that I need? Is this use-case worth the additional effort?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a pain though to keep track of the features you need to activate :/
Plus, with all crates requesting different features, I actually think we have to compile things multiple times to satisfy each combination. If the convention is to enable full
everywhere, we only need to compile every crate once to and the compiled artifact can be used for every crate's tests1.
I think the convenience of just saying "full" is worth it. Locally you have caches of everything so you will most likely just pay in linker time and if you modify your code between test executions, you gotta relink the test binary anyway so I am not sure it will matter in practice.
Can we try it out and if it negatively affects anything, figure out how to make it better?
Footnotes
-
This is an unproven hypothesis. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for elaborating. Using full
sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed my mind. Esp. working on libp2p-core
is quite painful now because every change there invalidates libp2p-core
artifact which causes a re-compile of every other crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 mind proposing a patch @thomaseizinger?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think the best way to resolve this is to actually stop the circular dependency. This will allow for proper caching of the build artifacts. It will also solve the issue I am currently facing with release-please
(#2902).
Co-authored-by: Max Inden <[email protected]>
Is it that large a change? Activate a couple of feature flags and your back in. No functionality is changing! |
…p2p into 2173-no-default-features
That would be great, yeah! |
I would be great to have a short section "How to upgrade" for the release, so folks now how to adjust their |
Is the first sentence in the changelog entry not good enough? https://github.com/libp2p/rust-libp2p/blob/2173-no-default-features/CHANGELOG.md#0490---unreleased |
I somehow missed that when looking through the diff. LGTM 👍 |
@thomaseizinger would you mind resolving the merge conflicts here? No rush, just a ping. |
Sure! I just didn't realize there are any :/ |
@mxinden Resolved. |
Wooooo! This is so exciting! |
As long as #2950 is still open, this could result in a very confusing experience for a beginner. We should definitely fix that. |
Circular dependencies are problematic in several ways: - They result in cognitive overhead for developers, in trying to figure out what depends on what. - They present `cargo` with limits in what order the crates can be compiled in. - They invalidate build caches unnecessarily thus forcing `cargo` to rebuild certain crates. - They cause problems with tooling such as `release-please`. To actually break the circular dependencies, this patch inlines the uses of `development_transport` in the examples and tests for all sub-crates. This is only meant to be a short-term fix until #3111 and #2888 are fixed. To ensure we don't accidentally reintroduce this dependency, we add a basic CI that queries `cargo metadata` using `jq`. Resolves #3053. Fixes #3223. Related: #2918 (comment) Related: googleapis/release-please#1662
Remove default features. You need to enable required features explicitly now. As a quick workaround, you may want to use the new `full` feature which activates all features.
Circular dependencies are problematic in several ways: - They result in cognitive overhead for developers, in trying to figure out what depends on what. - They present `cargo` with limits in what order the crates can be compiled in. - They invalidate build caches unnecessarily thus forcing `cargo` to rebuild certain crates. - They cause problems with tooling such as `release-please`. To actually break the circular dependencies, this patch inlines the uses of `development_transport` in the examples and tests for all sub-crates. This is only meant to be a short-term fix until libp2p#3111 and libp2p#2888 are fixed. To ensure we don't accidentally reintroduce this dependency, we add a basic CI that queries `cargo metadata` using `jq`. Resolves libp2p#3053. Fixes libp2p#3223. Related: libp2p#2918 (comment) Related: googleapis/release-please#1662
Description
This patch-set removes our use of
default
features. We also introduce a newfull
feature that activates all features.Links to any relevant issues
Open Questions
Change checklist
I have made corresponding changes to the documentation