Reduce dependency tree

[thomaseizinger]

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

- [ ] https://github.com/libp2p/rust-libp2p/pull/3514
- [ ] https://github.com/libp2p/rust-libp2p/pull/3513
- [ ] https://github.com/libp2p/rust-libp2p/pull/3512
- [ ] https://github.com/libp2p/rust-libp2p/pull/3510
- [ ] https://github.com/webrtc-rs/webrtc/pull/411
- [ ] https://github.com/libp2p/rust-libp2p/pull/3312
- [ ] `combine` is only brought in by `redis` through `interop-test`
- [ ] https://github.com/libp2p/rust-libp2p/issues/3659
- [ ] https://github.com/libp2p/rust-libp2p/issues/4449

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: https://github.com/async-rs/async-std/commit/bf316b095c176c8738c6401cc62d0bc389c88961.

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.

https://github.com/async-rs/async-std/compare/e1d66f5...fa29b50

[jxs]

Hi! Yeah there's an open issue for that: https://github.com/libp2p/rust-libp2p/issues/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

[tbu-]

async-std is officially discontinued: https://github.com/async-rs/async-std/blob/96f564672a8588ac0516e86580c249009ad3e94f/README.md.

[dariusc93]

async-std is officially discontinued: https://github.com/async-rs/async-std/blob/96f564672a8588ac0516e86580c249009ad3e94f/README.md.

Thank you for letting us know. In this case, we should probably deprecate async-std completely and in the next breaking release, remove it altogether. Thoughts on this @jxs @elenaf9?

[elenaf9]

Thank you for letting us know. In this case, we should probably deprecate async-std completely and in the next breaking release, remove it altogether. Thoughts on this @jxs @elenaf9?

Makes sense 👍

But I think we then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative. Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

[dariusc93]

But I think we then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative.

I would have to double check but we could an SmolExecutor if there is not one already and add it apart of SwarmBuilder, but I am all for just deprecating async-std without adding smol or additional executors as well (though others may have different opinions for that, which I am all for hearing)

Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

Im all for of keeping the abstractions and supporting multiple runtimes, either what we would support in our protocols or by allowing the user to supply their own runtime, though we should probably continue to prefer tokio (or wasm-bindgen-futures for wasm32 arch) while still leaving the abstraction for others to bring their own runtime if needed. That way we can avoid re-adding the abstractions in the future unless we are dead-set on using tokio through and through, though we would never know for sure if something would replace tokio in the future.

[jxs]

But I think we then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative.

Thanks for bringing this Elena, yeah we probably need to address it.

Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

true but tbh it seems the days of new runtimes are over, tokio has now become the de facto runtime right? smol has 300k downloads per month, tokio has 13 million

IMHO we'd just remove async-std code and stick to tokio, if anyone needs smol for a particular transport they can have and maintain a fork on their own repos, we can link to if if needed wdyt? But is there anyone still using async-std? cc @lyzkov since you were the only one commenting on https://github.com/libp2p/rust-libp2p/issues/4449#issuecomment-2507713803.

[elenaf9]

Opened a separate issue #5935 to discuss this.