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

feat(kad): make implementation modules private #3738

Merged
merged 29 commits into from
Apr 11, 2023

Conversation

tcoratger
Copy link
Contributor

Description

Similar to #3494, make implementation modules private for Kademlia (kad).

Resolves #3608.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • A changelog entry has been made in the appropriate crates

@tcoratger
Copy link
Contributor Author

@thomaseizinger Few questions/remarks here:

  • I deprecated all public modules inside kad except the struct Kademlia<TStore> to restrict to minimum and users only have access to this one.
  • If there are certain modules that must remain public, do not hesitate to tell me, I assumed that the user should only have access to the Kademlia<TStore> structure which implements the Kademlia protocol
  • As a result, in files that use a lot of deprecated elements, I placed a global #![allow(deprecated)] at the top of the file, rather than repeating the #[allow(deprecated)] statement several dozen times in the file, agreed?
  • I imagine that it is also necessary to withdraw public access on the enums which are for the moment largely public. Before doing this I wanted to be sure, should they all be removed or are there particular enums that the user should continue to have access to in public?
  • I have so far only added the corresponding line in the CHANGELOG. When all this is confirmed, I will add the list of deprecated modules here.

Copy link
Contributor

@thomaseizinger thomaseizinger left a 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.

protocols/kad/src/lib.rs Outdated Show resolved Hide resolved
@mergify
Copy link
Contributor

mergify bot commented Apr 5, 2023

This pull request has merge conflicts. Could you please resolve them @tcoratger? 🙏

Copy link
Contributor

@thomaseizinger thomaseizinger left a 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! :)

@thomaseizinger
Copy link
Contributor

Until we have #3735, what you'd also have to do is go through the public API of Behaviour (and everything that is actually meant to be public) and check that every type that is used there, either as an argument or as a return value is actually importable via a path that is not deprecated.

Does that make sense?

@tcoratger
Copy link
Contributor Author

Until we have #3735, what you'd also have to do is go through the public API of Behaviour (and everything that is actually meant to be public) and check that every type that is used there, either as an argument or as a return value is actually importable via a path that is not deprecated.

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?

@thomaseizinger
Copy link
Contributor

Until we have #3735, what you'd also have to do is go through the public API of Behaviour (and everything that is actually meant to be public) and check that every type that is used there, either as an argument or as a return value is actually importable via a path that is not deprecated.
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 libp2p-kad in our tests. I am gonna try and push #3735 forward which should fix this.

Copy link
Contributor

@thomaseizinger thomaseizinger left a 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.

protocols/kad/CHANGELOG.md Outdated Show resolved Hide resolved
protocols/kad/CHANGELOG.md Outdated Show resolved Hide resolved
protocols/kad/src/behaviour.rs Outdated Show resolved Hide resolved
@@ -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>> {
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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 :)

@mergify
Copy link
Contributor

mergify bot commented Apr 9, 2023

This pull request has merge conflicts. Could you please resolve them @tcoratger? 🙏

@thomaseizinger thomaseizinger changed the title feat(kad): Make implementation modules private feat(kad): make implementation modules private Apr 10, 2023
Copy link
Contributor

@thomaseizinger thomaseizinger left a 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.

thomaseizinger
thomaseizinger previously approved these changes Apr 10, 2023
@mergify mergify bot dismissed thomaseizinger’s stale review April 10, 2023 15:53

Approvals have been dismissed because the PR was updated after the send-it label was applied.

@tcoratger
Copy link
Contributor Author

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.

Yes happy to participate for this stage too!

@tcoratger
Copy link
Contributor Author

@thomaseizinger I received a notification to merge, normally it should not have changed anything

@thomaseizinger
Copy link
Contributor

@thomaseizinger I received a notification to merge, normally it should not have changed anything

Yeah it is queued, all done here :)

@thomaseizinger
Copy link
Contributor

Unfortunately, this PR seems to have some CI issues. I'll investigate.

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙏

@mergify mergify bot merged commit 4cac590 into libp2p:master Apr 11, 2023
@tcoratger tcoratger deleted the kad_private branch April 13, 2023 10:47
mxinden added a commit to mxinden/rust-libp2p that referenced this pull request Jun 6, 2023
Deprecated in libp2p#3738

Deprecation released with `v0.51.3`.

Follow up to libp2p#3896

Part of libp2p#3647
mergify bot pushed a commit that referenced this pull request Oct 25, 2023
Deprecated in #3738.
Follow up to #3896.
Part of #3647.

Pull-Request: #4035.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

kad: Make implementation modules private
3 participants