-
Notifications
You must be signed in to change notification settings - Fork 21
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
drop dependency on async-std #22
Conversation
also adds my name to the authors, updates all dependencies, and documents the available stores in the readme
@@ -35,7 +35,7 @@ | |||
// #![forbid(unsafe_code, future_incompatible)] | |||
// #![deny(missing_debug_implementations, nonstandard_style)] | |||
// #![warn(missing_docs, missing_doc_code_examples, unreachable_pub)] | |||
#![forbid(unsafe_code, future_incompatible)] |
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.
Wait, what becomes future incompatible? that is kind of a problem, as 2021 edition is going to be here in only a few months.
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.
The code isn't future-incompatible, but the lint itself was blowing up on nightly. I don't remember the exact message but it sounded like it was no longer necessary (or allowed?)
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.
Hmm, related to rust-lang/rust#81670 which I can't quite say I understand clearly.
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.
Does #![deny(future_incompatible)]
work fine on nightly?
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.
Ahh! Yep, I'll switch it to deny
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.
resolved in 89cd086
Co-authored-by: Jeremiah Senkpiel <[email protected]>
Update: This is actually a major change. Updating the crypto libraries changed their signatures and broke tide's tests. I'm going to publish this as 3.0.0, since we're post 1.0 |
Async-session is now a framework-independent interface, and should not depend on any specific runtime. Users of warp-sessions or other frameworks (trillium-sessions, soon) should not have to compile all of async-std just to get an async rwlock.
When this interface was written, it was primarily intended to support tide with a secondary goal of being framework independent. Now that it's already used by two (and soon three) frameworks, the crate should attempt to meet all of their needs as best as possible.
This PR also adds my name to the authors, updates all dependencies, and documents the available stores in the readme, since the tide documentation points there
If approved, I intend to release this, and believe it to be a patch change. There's a small breaking change that impacts none of the public dependent crates: Previously the
log
reexport was actually kv-log-macros, and now it's just thelog
crate.