Skip to content
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

Merged
merged 1 commit into from
Nov 19, 2024

Conversation

praveenperera
Copy link
Contributor

Closes: #102

@praveenperera praveenperera marked this pull request as draft October 13, 2024 21:28
@praveenperera
Copy link
Contributor Author

praveenperera commented Oct 14, 2024

can't seem to get this working with rust 1.63.0

when i run cargo update -p tokio-util --precise "0.7.11"

I get: error: package ID specification tokio-util did not match any packages

@praveenperera praveenperera marked this pull request as ready for review October 14, 2024 00:28
src/runtime.rs Outdated
#[cfg(feature = "async-std")]
pub use async_std::task::sleep;

#[cfg(not(any(feature = "tokio", feature = "async-std")))]
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@tnull tnull Oct 14, 2024

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Cargo.toml Outdated Show resolved Hide resolved
@praveenperera
Copy link
Contributor Author

@tnull @oleonardolima using a trait instead now

@praveenperera praveenperera force-pushed the remove-async-std-dep branch 5 times, most recently from f6695b3 to 35b6377 Compare October 15, 2024 17:50
@oleonardolima
Copy link
Collaborator

@tnull @oleonardolima using a trait instead now

Awesome! I'd still not bring async-std, and have only tokio as the default one, the user could use one of their choice and pass it when building the clients.

@praveenperera
Copy link
Contributor Author

praveenperera commented Oct 15, 2024

@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 async-std you can still use it as:

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.

@tnull
Copy link
Contributor

tnull commented Oct 15, 2024

@tnull @oleonardolima using a trait instead now

Awesome! I'd still not bring async-std, and have only tokio as the default one, the user could use one of their choice and pass it when building the clients.

Also +1 for dropping async-std as tokio is the (for better or worse) the most commonly used runtime.

@praveenperera
Copy link
Contributor Author

Alright guys you convinced me, I never use async-std or see it much anymore, I removed it completely.

Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

src/runtime.rs Outdated Show resolved Hide resolved
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"]
Copy link
Collaborator

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 ?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Cargo.toml Outdated Show resolved Hide resolved
Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@oleonardolima oleonardolima added the enhancement New feature or request label Oct 17, 2024
@oleonardolima oleonardolima requested review from notmandatory and ValuedMammal and removed request for tnull October 17, 2024 18:52
@coveralls
Copy link

coveralls commented Oct 17, 2024

Pull Request Test Coverage Report for Build 11880146166

Details

  • 8 of 16 (50.0%) changed or added relevant lines in 2 files are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage decreased (-0.4%) to 88.426%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/lib.rs 7 10 70.0%
src/async.rs 1 6 16.67%
Files with Coverage Reduction New Missed Lines %
src/async.rs 1 80.0%
Totals Coverage Status
Change from base Build 11879843924: -0.4%
Covered Lines: 1146
Relevant Lines: 1296

💛 - Coveralls

Cargo.toml Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/sleeper.rs Outdated Show resolved Hide resolved
src/sleeper.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@praveenperera
Copy link
Contributor Author

praveenperera commented Nov 7, 2024

utACK

It should be ready to go, just squash the commits into a single one as just the latest ones are applicable.

@oleonardolima I never usually do conventional commits, but is this a fix or a feat?

@oleonardolima
Copy link
Collaborator

Im not sure, but I would use refactor(retry)!: ..., as I consider it a breaking change on how the feature works.

@ValuedMammal
Copy link
Contributor

I think we will need #110 to get this to run in CI.

@ValuedMammal
Copy link
Contributor

@praveenperera Can you rebase?

@praveenperera praveenperera force-pushed the remove-async-std-dep branch 2 times, most recently from 7cae4b8 to 9963f27 Compare November 13, 2024 15:37
@praveenperera
Copy link
Contributor Author

@ValuedMammal done

Copy link
Contributor

@ValuedMammal ValuedMammal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 9963f27

@ValuedMammal
Copy link
Contributor

Code review ACK

It could use some documentation improvements, but that can be done in a follow up PR. I tested upgrading bdk_esplora to use this branch and it seems to work. For the record I did not try using the async client with a runtime other than tokio, but I'm interested in confirming if this change will be suitable to use for example in a WASM environment.

Cargo.toml Outdated Show resolved Hide resolved
@MaxFangX
Copy link
Contributor

I can confirm that this patch compiles and works in our downstream code after reducing the tokio requirement from 1.38->1.36.

Copy link
Collaborator

@oleonardolima oleonardolima left a 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
Comment on lines 74 to 75
#[cfg(feature = "async")]
use r#async::Sleeper;
Copy link
Collaborator

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.

src/lib.rs Outdated Show resolved Hide resolved
@praveenperera praveenperera force-pushed the remove-async-std-dep branch 2 times, most recently from 6346012 to a5aa7f4 Compare November 17, 2024 15:37
Copy link
Contributor

@ValuedMammal ValuedMammal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reACK 27c4125

Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ValuedMammal ValuedMammal merged commit 9f4b3b9 into bitcoindevkit:master Nov 19, 2024
25 checks passed
@praveenperera praveenperera deleted the remove-async-std-dep branch November 19, 2024 18:40
notmandatory added a commit to bitcoindevkit/bdk that referenced this pull request Dec 6, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rust-esplora-client shouldn't introduce an async runtime
6 participants