Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to reduce the number of dependencies for both development and production environments.
Production Dependencies
Before, on my machine, building the library requires pulling in 49 crates. This is not so bad, but when I looked into the project manifest, I realized that a huge bulk of the bloat comes from the
futures
crate.Hence, the first two commits of this PR addresses this issue by replacing the
futures
crate for the much more lightweightfutures-core
crate in production environments. Thefutures-core
crate provides the most minimal interface for theStream
trait.Overall, this reduces the number of built crates from 49 to 22. That's a significant improvement! This was mostly due to the fact that the
futures
crate packages an executor by default (among other unused imports), whereas thefutures-core
crate only exposes core traits. Sincebmrng
only used theStream
interface, there is no need for the executor (and other imports).Development Dependencies
Meanwhile, following the removal of the
futures
crate in all environments, thefutures-util
crate (which depends onfutures_core
) is used to regain access to theStreamExt
utilities for tests.Finally, the development dependency on
tokio-test
has also been removed. The tests only usedtokio-test
for theassert_ok
andassert_err
macros, which may easily be emulated by the built-inassert
macro with theResult::is_{ok|err}
methods.While I was there in the tests, I also refactored multiple instances of redundant Boolean assertions. That is:
If there are any issues with this PR, please do let me know. I will gladly resolve them! Thanks!