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.

Sign up for GitHub

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

Jump to bottom

Re-organising crate structure #3271

Open
4 of 8 tasks
thomaseizinger opened this issue Dec 21, 2022 · 1 comment
Open
4 of 8 tasks

Re-organising crate structure #3271

thomaseizinger opened this issue Dec 21, 2022 · 1 comment
Labels
tracking-issue Issues which are the entry point to bigger projects.

Comments

@thomaseizinger
Copy link
Contributor

thomaseizinger commented Dec 21, 2022 •
edited
Loading

Pitch

The current workspace and dependency structure is heavily guided by its own history. We've moved around many components since it was created and refactored various interfaces. It is time to take a step back and look at the code holistically to organise it in such a way that code that changes together lives together. This will help with:

  • Making fewer breaking changes: For example, no more breaking changes in protocols unless the NetworkBehaviour interface changes.
  • Better compile times: Smaller, cohesive crates means more parallelism during the compilation phase
  • Easier to understand: Currently, it is unclear what the purpose of libp2p-core is other than "stuff that everything depends on"

Vision

libp2p wants to be a modular networking stack. To make this easy, users need to be able to maintain their own libp2p-compatible networking out-of-tree without much friction. This requires somewhat stable interfaces which we are hoping to provide with this restructuring.

Approach

I've already outlined some ideas in #3072 (comment). This issue is to track concrete work items into getting there. The basic idea is to break up libp2p-core and libp2p-swarm into more focused crates that provide minimal interfaces that are required for interoperability.

The following list tries to be ordered. Untangling dependencies can be tricky so I am probably going to miss something. In case someone picks up an item, keep that in mind :)

Tasks
Preview Give feedback
  1. Extract libp2p-identity crate #3349
  2. core: make upgrade::apply an implementation detail of transport upgrades #3748
    thomaseizinger
  3. core: remove upgrade::transfer module #4011
    4 of 4
    getting-started help wanted priority:nicetohave
  4. transport: remove address_translation functionality from Transport trait #3953
@thomaseizinger thomaseizinger added help wanted priority:important The changes needed are critical for libp2p, or are blocking another project labels Dec 21, 2022
@thomaseizinger
Copy link
Contributor Author

I am flagging this as priority:important because I think the current rate of breaking changes is not sustainable for our users.

@thomaseizinger thomaseizinger mentioned this issue Jan 17, 2023
Merged
4 tasks
mergify bot pushed a commit that referenced this issue Jan 17, 2023
@thomaseizinger
refactor(core)!: remove EitherError in favor of either::Either (#…
f4fed38 
…3337)

Defining our own `EitherError` type has no value now that `Either` provides the same implementation.

Related: #3271
This was referenced Jan 18, 2023
Closed
Closed
@thomaseizinger thomaseizinger mentioned this issue Feb 6, 2023
Closed
This was referenced Mar 13, 2023
Merged
Closed
@thomaseizinger thomaseizinger mentioned this issue Mar 29, 2023
Open
This was referenced Apr 19, 2023
Merged
Merged
mergify bot pushed a commit that referenced this issue Apr 25, 2023
@thomaseizinger
feat(core): deprecate {In,Out}boundUpgradeExt
585a84e 
These functions were only used for some code in the interop-tests which is easily mitigated and perhaps even easier to understand now. We can thus deprecate these functions and their related types and thereby reduce the API surface of `libp2p-core` and the maintenance burden.

This change is motivated by the work around making protocols always strings which requires/required updates to all these upgrades.

Related #3806.
Related #3271.
Related #3745.

Pull-Request: #3807.
mergify bot pushed a commit that referenced this issue Apr 26, 2023
@thomaseizinger
feat(core): deprecate OptionalUpgrade
e5dbeb3 
This is dead-code, we don't use it in our codebase. I am suggesting to remove it because it creates an unnecessary API surface.

Related: #3747.
Related: #3271.

Pull-Request: #3806.
@thomaseizinger thomaseizinger mentioned this issue Jun 23, 2023
Closed
@thomaseizinger thomaseizinger mentioned this issue Jul 20, 2023
Merged
@thomaseizinger thomaseizinger mentioned this issue Aug 24, 2023
Merged
4 tasks
@thomaseizinger thomaseizinger added priority:important The changes needed are critical for libp2p, or are blocking another project tracking-issue Issues which are the entry point to bigger projects. and removed priority:important The changes needed are critical for libp2p, or are blocking another project labels Sep 20, 2023
@thomaseizinger thomaseizinger changed the title Tracking issue for re-organising crate structure Re-organising crate structure Sep 20, 2023
@thomaseizinger thomaseizinger removed the priority:important The changes needed are critical for libp2p, or are blocking another project label Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
tracking-issue Issues which are the entry point to bigger projects.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@thomaseizinger