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

drop dependency on async-std #22

Merged
merged 4 commits into from
Jun 1, 2021
Merged

drop dependency on async-std #22

merged 4 commits into from
Jun 1, 2021

Conversation

jbr
Copy link
Member

@jbr jbr commented May 29, 2021

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 the log crate.

also adds my name to the authors, updates all dependencies, and documents the available stores in the readme
README.md Outdated Show resolved Hide resolved
@@ -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)]
Copy link
Member

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.

Copy link
Member Author

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?)

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

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

resolved in 89cd086

jbr and others added 2 commits May 31, 2021 12:21
@jbr jbr merged commit 29840b2 into http-rs:main Jun 1, 2021
@jbr
Copy link
Member Author

jbr commented Jun 1, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants