-
Notifications
You must be signed in to change notification settings - Fork 176
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
Support both http 0.2 and 1.0 #684
Conversation
Thanks! The problem with this solve is that the implementations are mutually exclusive. That means if some project get diamond dependencies on
The immediate problem can of course make one of the flags "win", but that wouldn't help impls that depend on one that doesn't win. What are the drivers for solving the retaining of the old dependency? |
They aren't, they're entirely independent.
Avoiding breakage of code relying on the previous API. If it had been documented that the |
Hmm, it's less than I thought, if I did this correctly these should be the only (published) crates that are likely currently broken with ureq 2.9.0: > fd -0tf -Econfig.json '' crates.io-index | xargs -0 tail -qn1 | jq -r '.name as $name | .deps[] | select(.name == "ureq" and (.features | contains(["http-interop"]))) | $name'
crates-index
cargo-dl
cargo-features-manager
cargo-upgrades EDIT: Quickly testing them, |
Alright. Let's try to land this. Would it be possible to duplicate |
Done. It doesn't really reduce the diff but it does probably make it more readable. |
I'll do the rest here. Thanks! |
In released version 2.9.1, renamed the |
Did you forget to remove this planned removal from https://github.com/algesten/ureq/blob/main/FUTURE.md, after borrowing the suggested implementation from it? |
This implements the idea I had in #683, supporting both versions of
http
and with the planned breaking change to supportingTryFrom<http::request::Builder>
instead ofFrom<http::request::Builder>
since it's non-breaking as a new feature.