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

Consider replacing http-types crate with http crate #1644

Open
svix-jplatte opened this issue Apr 19, 2024 · 4 comments · May be fixed by #1662
Open

Consider replacing http-types crate with http crate #1644

svix-jplatte opened this issue Apr 19, 2024 · 4 comments · May be fixed by #1662

Comments

@svix-jplatte
Copy link

svix-jplatte commented Apr 19, 2024

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
Copy link
Author

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
Copy link
Member

heaths commented May 13, 2024

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.

@svix-jplatte svix-jplatte linked a pull request May 15, 2024 that will close this issue
@cataggar
Copy link
Member

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
Copy link
Member

heaths commented May 15, 2024

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?

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 a pull request may close this issue.

3 participants