[cmrdporcupine]

+1 for #1. In general, I would recommend providing non-async alternative APIs, with the async runtime as an option rather than assumed default. Not all of us drink the kool-aid there. And no, I don't mean just providing a "sync" API that uses "block_on" behind the scenes but still uses tokio...

Also, for async don't mandate tokio, use the "agnostic" crate to abstract it so people can use alternative runtimes.

And yes, don't use anyhow in a library like this. Anyhow is for your internal code, not public libraries/crates. Define a set of error enums, or use thiserror for it if you have to.

[cat-whisperer]

Yup, I am planning to use thiserror and error-stack for this in the future updates. But, anyhow provides an insanely easy interface for the person using this library, and keeps their mind off the error handling and rather in managing the domain stuff.

[dhon_]

Could you elaborate on why using block_on wouldn't be an acceptable solution for users that want a blocking API?

[cmrdporcupine]

Why would I want to add tokio as a dependency if I don't use it?

[dhon_]

Yes you're right. I'd assumed that tokio was used internally in the UI but from a cursory read it doesn't seem to be the case.

[cat-whisperer]

I was thinking of making it a opt-in feature, but I saw most of the usecases that I might have, might need concurrency and a runtime.

[cat-whisperer]

it definitely would be, that was my intention. By passing in a runtime you can either block or schedule. Giving you control on what you want to be concurrent and what you don’t.