Reduce dependency tree

[thomaseizinger]

I'll record various efforts in here to reduce the size of our dependency tree where possible.

Tasks

Preview Give feedback

1. refactor: don't depend on multihash features #3514
   +0
2. refactor(interop-test): remove easy to replace strum dependency #3513
   +0
3. refactor(interop-tests): disable unused features #3512
   +0
4. feat(noise): remove tests for deprecated protocol #3510
   send-it +1
5. Remove derive_builder dependency webrtc-rs/webrtc#411
   +0
6. feat: migrate to quick-protobuf #3312
   +0
7. combine is only brought in by redis through interop-test
8. Switch from webrtc-rs to str0m #3659
   difficulty:hard help wanted priority:nicetohave +3
9. Prefer tokio runtime everywhere #4449
   difficulty:easy help wanted priority:nicetohave +3

More suggestions welcome, a good place to start is a timings report by cargo of the entire workspace (minus dev-dependencies): cargo build --workspace --all-features --timings. Once you have identified a (ideally heavy) dependency that we might not need, investigate with cargo tree -i -p <dependency> where it comes from.

[tbu-]

Might it be possible to get rid of the async-std (optional) dependency? I'd guess the ecosystem has moved on to tokio these days, with the last commit in async-std being 9 months ago: async-rs/async-std@bf316b0.

I think this could help cutting down some more dependencies as well.

[thomaseizinger]

I am not following the async-std development but I'd consider that one too established to remove.

Plus, it is optional as you said. I think it would be more fruitful to investigate for dependencies in our protocol crates like yamux, gossipsub or kademlia.

[thomaseizinger]

Might it be possible to get rid of the async-std (optional) dependency? I'd guess the ecosystem has moved on to tokio these days, with the last commit in async-std being 9 months ago: async-rs/async-std@bf316b0.

I think this could help cutting down some more dependencies as well.

We can cut down some dependencies by moving all our tests and examples to tokio. async-std is heavily feature-flagged, meaning we can reduce our dependencies by only activating the bare minimum features needed in the various transports and libp2p-swarm.

[tbu-]

We can cut down some dependencies by moving all our tests and examples to tokio. async-std is heavily feature-flagged, meaning we can reduce our dependencies by only activating the bare minimum features needed in the various transports and libp2p-swarm.

Would you reconsider removing async-std entirely today? async-std development seems to be entirely dead. In the last 1.5 years since your comment, there has been +128 -79 lines of change in async-std, mostly compilation fixes, doc changes and dependency updates.

async-rs/async-std@e1d66f5...fa29b50

[jxs]

Hi! Yeah there's an open issue for that: #4449

[tbu-]

That issue is not about removing async-std support.

For now, we want to keep supporting async-std

I'd advocate for removing async-std support since supporting multiple runtimes makes the code more complex — and async-std seems to be dead, with around 200 lines changed in 1.5 years.

[jxs]

That issue is not about removing async-std support.

Yeah you are right sorry, cannot find the phase out discussion post, probably was discussed on a call.
Basically the plan is to first prefer tokio everywhere first, and then removing async-std