-
Notifications
You must be signed in to change notification settings - Fork 47
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
Remove async std dependency #103
Remove async std dependency #103
Conversation
6718f1c
to
fdc7aed
Compare
can't seem to get this working with rust 1.63.0 when i run I get: |
src/runtime.rs
Outdated
#[cfg(feature = "async-std")] | ||
pub use async_std::task::sleep; | ||
|
||
#[cfg(not(any(feature = "tokio", feature = "async-std")))] |
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.
Mhh, in general features should be additive, so I'm not sure we want to add a layer of non-additive features here. Also the choice between tokio
and async-std
is pretty limited, and given the former is the defacto standard by now we may as well drop async-std
entirely, IMO. I also think we should introduce a Sleeper
trait an provide a tokio
-based default implementation, allowing users to implement it any other way too, instead of only allowing these two choices.
E.g., I think WASM users won't be able to use tokio
, and it looks like they won't be able to use async-std
either (cf. async-rs/async-std#220). So, this change would really won't leave a way for them to keep using the esplora client, IIUC. (Although that issue is now kind of pre-existing since the async-std
dependency has been introduced.
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.
I’m good with only supporting Tokio.
I think WASM users would just use the blocking client and skip the async features all together?
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.
Adding tokio
or async-std
would only be needed is the async features is also enabled.
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.
I think WASM users would just use the blocking client and skip the async features all together?
I don't think they can use the blocking client. Usually WASM is async-everything but it's driven by WASM's own executor. So AFAIK we need to allow for a way to bring your own runtime to let them continue to use the rust-esplora-client
crate.
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.
Interesting, i didn't know that, i've only used WASM for any network calls just number crunching. Does their runtime have a task too? Could we use that with features and conditional compilation?
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.
Interesting, i didn't know that, i've only used WASM for any network calls just number crunching. Does their runtime have a task too?
Mhh, I'm not sure, I think most of them are just using wasm_bindgen
and did so successfully previously with rust-esplora-client
and projects based on it. AFAIK just using async reqwest
works decently.
Could we use that with features and conditional compilation?
I really don't think we should go there and introduce even more assumptions on how the user wants to use the library, which is essentially a a bunch of types, i.e., a thin wrapper around an HTTP client. I think the API of this crate should be flexible but overall kept very very simple. Tbh, I don't see a reason why this crate should have much more than a single dependency on serde_json
, especially when we end up going the #97 direction.
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.
I think that makes sense, as long as we keep the logic for retires and that kinda stuff.
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.
I agree with tnull's comments, I think it's pretty straightforward to have and use a Sleeper
trait, using the tokio
(already existing one) as the default batteries included implementation, alongside allowing the user to implement their own, for example, gloo-timers
for WASM.
@tnull @oleonardolima using a trait instead now |
f6695b3
to
35b6377
Compare
Awesome! I'd still not bring |
@oleonardolima I could get rid of it, but its an optional dep and I thought it would be nice keep in there because if it's zero cost if you don't use it and if you are using Builder::new(...) Instead of struct AsyncStd;
impl Runtime for AsyncStd {...}
Builder::<AsyncStd>::new_custom_runtime(....) If you don't think its worth it tho, I'll get rid of it. |
Also +1 for dropping |
Alright guys you convinced me, I never use |
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.
I guess there are some old commits that could be dropped, or everything squashed into a single one.
I'm still unsure about the appropriate feature structure, looking forward to have other's opinions about it.
Cargo.toml
Outdated
blocking = ["minreq", "minreq/proxy"] | ||
blocking-https = ["blocking", "minreq/https"] | ||
blocking-https-rustls = ["blocking", "minreq/https-rustls"] | ||
blocking-https-native = ["blocking", "minreq/https-native"] | ||
blocking-https-bundled = ["blocking", "minreq/https-bundled"] | ||
async = ["async-std", "reqwest", "reqwest/socks"] | ||
|
||
tokio = ["dep:tokio", "async"] |
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.
I wonder if we do need to have tokio as a separate feature, maybe we can have as part of the async one, as we did for async-std, still unsure about it. WDYT ?
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.
I think it makes sense, its a default feature, but if a user wanted to use a different async runtime, but still wanted to use reqwest, without tokio like in WASM, they could disable default features and add wasm
and async
, features.
I think it gives more flexibilty without adding annoyance since its a default feature.
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.
Yes, I was afraid of bringing some other unwanted dependencies through tokio
, but reqwest
already uses it with features net
and time
, so it should be unified, looks fine.
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.
It seems to be failing regarding using only blocking
feature, I left some comments/suggestions.
6c26120
to
d248d90
Compare
Pull Request Test Coverage Report for Build 11880146166Details
💛 - Coveralls |
@oleonardolima I never usually do conventional commits, but is this a |
Im not sure, but I would use refactor(retry)!: ..., as I consider it a breaking change on how the feature works. |
01fd667
to
7cae4b8
Compare
I think we will need #110 to get this to run in CI. |
@praveenperera Can you rebase? |
7cae4b8
to
9963f27
Compare
@ValuedMammal done |
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.
ACK 9963f27
Code review ACK It could use some documentation improvements, but that can be done in a follow up PR. I tested upgrading |
I can confirm that this patch compiles and works in our downstream code after reducing the tokio requirement from 1.38->1.36. |
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.
utACK 9963f27
src/lib.rs
Outdated
#[cfg(feature = "async")] | ||
use r#async::Sleeper; |
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.
nit: we wouldn't need this other import if we use the full r#async::Sleeper
below instead. Could be addressed in a future PR.
6346012
to
a5aa7f4
Compare
a5aa7f4
to
27c4125
Compare
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.
reACK 27c4125
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.
tACK 27c4125
Thanks for working on this one!
It looks pretty straightforward right now, and I was able to run it as examples with custom async-std
and gloo-timers
, instead of the default tokio
runtime while only relying on the async-https
feature.
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.
LGTM
90fd1a2 docs(esplora): update README.md (valued mammal) f0e6395 deps(esplora): bump `esplora-client` to 0.11.0 (valued mammal) Pull request description: Update `bdk_esplora` to depend on esplora-client 0.11.0 ### Notes to the reviewers bitcoindevkit/rust-esplora-client#103 added a generic type parameter to `AsyncClient` representing a user-defined `Sleeper` and that change is reflected here in order to call the underlying API methods. We also add a new build feature "tokio" that enables the corresponding feature in rust-esplora-client. closes #1742 ### Changelog notice `bdk_esplora`: Bump `esplora-client` to 0.11.0 ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing * [x] This pull request breaks the existing API * [x] I'm linking the issue being fixed by this PR ACKs for top commit: notmandatory: tACK 90fd1a2 oleonardolima: ACK 90fd1a2 Tree-SHA512: 98d529d3bb0dbbf4bbafeea7d30ec5e5816ac9800ba2cb7981fc6189b4b02774956c3ddbb74bf0b3e6e22798bfced36508263e4e89c248b7a6240c5c7109107b
Closes: #102