-
Notifications
You must be signed in to change notification settings - Fork 1k
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
feat(kad): make implementation modules private #3738
Conversation
@thomaseizinger Few questions/remarks here:
|
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 submitting this PR! I think there is an easier solution, plus we shouldn't use allow(deprecated)
but rather fix the deprecation warnings in our own codebase. For this, we need to offer a migration path. Anything that actually triggers a deprecation warning while using kademlia needs to be exported from the root module (the out-event, config, etc) of libp2p-kad
as not deprecated.
Keep in mind of what the overall goal is: We only "deprecate" these modules because we want to tell users in a backwards-compatible way that they should not depend on this stuff. This way, we may get feedback early about use-cases that may actually need these types. The hypothesis is that nobody does which then means we can just make them private.
This reverts commit 0ff0ef7.
This pull request has merge conflicts. Could you please resolve them @tcoratger? 🙏 |
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.
Yes that looks good to me! :)
Until we have #3735, what you'd also have to do is go through the public API of Does that make sense? |
Yes sure understood, we should check at compile time, if we don't get a deprecation alert then everything is fine in all folders and subfolders, correct? |
Yes although I am not sure that we exhaust the entire public API of |
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.
This is looking good already, thank you!
Please give the public API of Behaviour
a quick scan and check what types appear in there, those should be exported from the root module. It is a non-breaking change so if we miss something, it is not the end of the world, people can suppress the deprecation warning and we can ship another patch release where we add a re-export but ideally, it should be a smooth upgrade.
@@ -624,19 +624,20 @@ where | |||
pub fn remove_peer( | |||
&mut self, | |||
peer: &PeerId, | |||
) -> Option<kbucket::EntryView<kbucket::Key<PeerId>, Addresses>> { | |||
let key = kbucket::Key::from(*peer); | |||
) -> Option<kbucket_priv::EntryView<kbucket_priv::Key<PeerId>, Addresses>> { |
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 this is one example of a public API that returns a now "private" type.
We need to export EntryView
at the root to allow users to reference this type without deprecations.
Can you scan for others as well please?
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.
@thomaseizinger Done, just didn't export these ones (which are only used inside functions and therefore not intended to be public as far as I understand):
kbucket_priv::Entry
kbucket_priv::InsertResult
kbucket_priv::Distance
kbucket_priv::Node
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.
Sounds good, thank you!
It is not a drama if we missed something as they are still accessible via the deprecated modules so a users can open an issue and tell us :)
This pull request has merge conflicts. Could you please resolve them @tcoratger? 🙏 |
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.
Thank you!
Making the modules private makes it much easier for us to maintain this crate. Looking forward to removing the deprecated modules in the next breaking release.
Approvals have been dismissed because the PR was updated after the send-it
label was applied.
Yes happy to participate for this stage too! |
@thomaseizinger I received a notification to merge, normally it should not have changed anything |
Yeah it is queued, all done here :) |
Unfortunately, this PR seems to have some CI issues. I'll investigate. |
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.
🙏
Deprecated in libp2p#3738 Deprecation released with `v0.51.3`. Follow up to libp2p#3896 Part of libp2p#3647
Description
Similar to #3494, make implementation modules private for Kademlia (
kad
).Resolves #3608.
Change checklist