Repository navigation
Replace cap-async-std #408
Description
cap-async-std has been removed without a replacement (see #399), because async-std is no longer maintained.
Now there is no way of using async code with this crate.
It would make sense to add either a:
- cap-tokio (I would prefer this one)
or a
- cap-smol
crate to this repository to retain the async functionality of this project.
Activity
sunfishcode commentedon Feb 15, 2026
Either of those would indeed be nice to do. I myself don't have the bandwidth to do them, however.
Ericson2314 commentedon May 11, 2026
I just started trying to slop
cap-tokiointo being.cgwalters commentedon Jun 8, 2026
Personally, I think it's simpler and actually more efficient in some ways to just encapsulate high level cap-std workflows (i.e. more than one operation) into a tokio
spawn_blockingthread.ssokolow commentedon Jul 15, 2026
To be honest, I'm preparing to either borrow code from #414 for my project or vendor a copy of
tokio::fs::read_dirwhere I swap out the wrappedstd::fs::read_diroperations forcap_std::fs::Dir::read_dirones.If for no other reason, because I tend to work with folders large enough that being able to cleanly abort retrieving a list of contents is valuable and Tokio already figured out the DOs and DON'Ts of incorporating read_dir into it.
I hope this won't be another case of "The
imagecrate closed my request, so now I have to vendor a copy of their code because what I want is literally their glue code that can't be meaningfully written any other way, but with a means to use the APIs provided by the underlyingpngcrate to inject some XDG Thumbnailing Spec metadata in the process".