Azure / azure-sdk-for-rust

This repository is for active development of the *unofficial* Azure SDK for Rust. This repository is *not* supported by the Azure SDK team.
MIT License
680 stars 232 forks source link

Consider replacing http-types crate with http crate #1644

Open svix-jplatte opened 2 months ago

svix-jplatte commented 2 months ago

Hey, I noticed you are using the unmaintained http-types crate for a little bit of codegen, plus its StatusCode and Method types. This is a tiny fraction of the functionality it includes, especially if you consider all of its dependencies.

There is a much more minimal crate for HTTP types that is actively maintained and seems like it should fulfill all of your needs: https://crates.io/crates/http. Would you consider switching to it? It would of course be a breaking change. I might be able to post a PR if you're interested.

svix-jplatte commented 1 month ago

For extra context, the http crate is not just an alternative crate, it's maintained by Sean McArthur alongside hyper, the most popular HTTP implementation for Rust by far. It's also used in reqwest, axum, actix-web, the AWS SDK, wiremock and many more crates / projects.

@heaths Hope you don't mind the ping, I think this is somewhat important as the current state of affair raises clear red flags for anybody who reviews their dependency trees.

heaths commented 1 month ago

I'd consider a PR, but there'll be a lot of changes coming up. We're planning to reduce dependencies as much as possible and practical and, IMO, pulling a crate just for a few simple types isn't worth the extra risk and build time. All that work is happening in a separate feature branch which we'll talk about in the not-so-distant future more. So whether you want to spend the time on a PR or not is up to you. As long as it isn't huge I'm happy to review, but it's not a high priority for me.

That said, this code - these crates - will be community-maintained (including me, since this was always unofficial) for the foreseeable future so it may be good to remove a dead dependency as you suggest.

cataggar commented 1 month ago

Two years ago, I took us the other way. We were removing the http dependency in favor of our own types in azure_core and some types from http_types. Probably worth revisiting some of the notes:

cc @yoshuawuyts

heaths commented 1 month ago

I appreciate that Rust, like JS, is a smattering of smaller crates comprising libraries; however, while we've always preferred first-party or even no dependencies, the "recent" events - not just xz - certainly up the priority. Governance is important, as is maintenance. I see http-types hasn't been touched in a couple years (though it's fairly basic, relatively speaking, and maybe hasn't needed it). Is that expected to be maintained (even review/merge PRs as needed) going forward? I see @yoshuawuyts is the biggest contributor.

I've looked through the other issue and PR you mentioned, but I don't understand in what scenarios compatibility with http-types is necessary (based on this comment). @cataggar care to elaborate?