-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
Stop using the async-std crate #531
Conversation
The async-std crate didn't had a release in 1 1/2 years and is pulling in a lot of outdated and unnecessary dependencies. Therefore I replaced all uses with actively maintained crates.
faf1ae6
to
c01630a
Compare
@@ -844,8 +844,8 @@ impl Connection { | |||
/// # // https://gitlab.freedesktop.org/zeenix/zbus/-/jobs/34023494 | |||
/// # #[cfg(all(not(feature = "tokio"), not(target_os = "windows")))] | |||
/// # { | |||
/// use async_global_executor::{block_on, spawn}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment needs to be adjusted
/// Here is how one would typically run the zbus executor through async-std's single-threaded
/// scheduler:
We could also use smol
instead of async-global-executor
. But that might pull more dependencies.
Thanks but async-std is only a dev dep so it dragging in obsolete deps isn't a very compelling argument, I'm afraid. I still want to ensure that zbus continues to work with it. We primarily use smol-rs crates. Dev deps are irrelevant to our users. Developers shouldn't need to care about async-std being under-mai tainted. Having said that, if any of the deps brought in by async-std has any security issues, it'd be definitely a compelling argument as we wouldn't want contributors to compromise their dev env. |
The problem with dev dependencies is that distros have to package them as well if they want to run tests. And since the deps of async-std are outdated there will be several versions of the same crate that have to be packaged. |
Oh, I didn't think/know of this aspect. This changes things for sure. :) I think it'd be best to just use tokio then, since it is the most popular runtime. Could you kindly provide a PR for that? |
Cool. I will hopefully get back to it later this month. |
Actually, looking at the repo, I still see sufficient recent activity on the project and one year is not that long for a release of a stable project. We've ourselves haven't had a release for more than 6 months now. 😞 Has this already presented an issue for a distro? |
|
Well, the general situation with distros packaging rust apps is not great. One reason that has been reported is the amount of dependencies needed, yes. If this specifically is the most important part, idk. Right now, zbus is pulling a bunch of older versions of crates that cause us to depend on multiple versions. Maybe that would be more important to tackle first https://sophie-h.pages.gitlab.gnome.org/cargo-lock-analyzer/ |
I think this wouldn't be relevant here if the distros didn't insist on dev deps being packaged as well.
I'd more more than happy to update deps where possible. I'm also pushing for Anyway, please do update the PR as discussed before. It's almost been one month now. 😆 |
The async-std crate didn't had a release in 1 1/2 years and is pulling in a lot of outdated and unnecessary dependencies.
Therefore I replaced all uses with actively maintained crates.