[Request]: Reduce dependencies and improve no_std friendliness

[ft-filancore]

Feature description

While working with this crate, I have noticed a few corners I'd rather cut:

• dependency on async_trait
• dependency on anyhow
• using std types where alloc would suffice

All of these are rather easy to address with a MSRV bump and minor refactoring.

Btw: it would be nice if this crate could be published on crates.io. It should meet all necessary requirements for that.

Motivation

While porting some IOTA stardust code to IOTA rebased, I needed to integrate this crate's traits into our project. It actually simplified quite a few messy key handling situations.

In the process of porting, I was glad to be able to throw out many uses of async-trait with rebased because other IOTA crates have an MSRV of 1.85. The remaining usage of async-trait in our codebase remain in the traits of this crate. So I was wondering: if there are seemingly no consumers with such a low MSRV, maybe it would be possible to bump it to Rust 1.75 and use RPITIT (fn() -> impl Future<Output = >), dropping the async-trait dependency?

Similarly, I wondered why this pulls in a full anyhow setup for error handling. After all, this is a library. The common ground in the Rust ecosystem is that anyhow is more application-oriented. If your Error::Other needs generic errors, is there a reason it can't be Box<dyn std::error:Error>?

Last but not least, we are implementing these traits in crates that we intend to ship on lower end machines with targets that do not have a full std library. But these targets have alloc. So it would be great, if this library could reduce its assumptions about the std library (of which it actually does not need too much) by being no_std with extern crate alloc; and feature-gating pure-std features. If you would bump the MSRV to Rust 1.81 I don't see any real need for std at all because you could then leverage core::error::Error.

Requirements

Okay, the template requires this but just as a repetition of the feature description rephrased as requirements:

• This library should have the least dependencies possible.
• Core features and alloc should be preferred over std to enable no_std usage.
• Std library features should be gated behind a std feature flag.
• This library should be published to crates.io.

Open questions

If you want, I'd be happy to contribute any/all of these changes. I'd also be happy to discuss our usage of the crate and design.

Are you planning to do it yourself in a pull request?

Yes

[qrayven]

Hey, thanks for the feedback. This sounds good. I have a question about async_trait, though. Could you clarify your use case and why you think removing async_trait would be better? From our perspective, we wanted to make the secret storage trait more universal.
Native async traits are not yet fully stabilized and are still less functional than the original async_trait. They are static, which significantly reduces flexibility - especially when working with trait objects and plugin-like solutions, which we find could be a useful use case.

[ft-filancore]

Could you clarify your use case and why you think removing async_trait would be better? From our perspective, we wanted to make the secret storage trait more universal.

With Rust's 2024 edition and associated lifetime adjustments around RPITIT, you do not necessarily need async_trait for non-static futures anymore. At least in our code base we get by without. An edition jump to 2024 may be too much for you, so I'm perfectly happy with dismissing this reason if you need broader MSRV or edition compatibility.

Furthermore, I see this primarily as a trait definition library, so my suggestions lean heavily in favor of not using dependencies when not strictly necessary. Every dependency that is needed to implement the trait is one additional dependency a consumer library has to explicitly import. And especially in Rust's imperfect no_std ecosystem one dependency that may break no_std guarantees by accidentally using std somewhere (if I see it correctly, async-trait upstream has no CI checking it does not break no_std compatibility).

The last reason I had considered when opening this issue is actually void (I remembered async_trait not being no_std compatible but they seem to have rectified this years ago, so my assumption there was simply out of date).

Having said all that: please consider the async_trait bullet point in the issue the least important for our use case as a whole. no_std compatibility and removal of anyhow is much more important to us.

[qrayven]

Thanks for explaining. Yeah, Rust 2024 significantly improves lifetime handling for futures, but it still doesn’t address the possibility of using dynamic dispatch. Additionally, as you mentioned, we would need to switch to the 2024 edition, which is not yet standardized across all repositories. I agree regarding the dependencies—we should aim to reduce them.
From our perspective, it would be ideal to hold off on removing async_trait for now and reconsider once async traits are fully stabilized in Rust. The plan is for that to happen this year.

Regarding no_std and anyhow - full agreement. I already have a draft prepared (not a final version and not tested), but feel free to leave comments #6