Consider replacing http-types crate with http crate

[svix-jplatte]

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]

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]

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]

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:

• add Method & StatusCode to azure_core #849
• switch Method and StatusCode to http-types #860

cc @yoshuawuyts

[heaths]

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?

[svix-jplatte]

Gentle ping on this

[heaths]

This is not currently a priority. The issue is left open as a tracking issue because I do want to get to this eventually, but we're trying to get our first betas out built on the new TypeSpec code emitter like all our other languages use (for their respective languages).

I'd rather remove the dependency on http or http-types entirely. It's not worth the build time for 2 simple types. What we'll end up with will likely be compatible with what we have now, so it'd be easy enough to map from one representation to another.

From the OP,

It would of course be a breaking change. I might be able to post a PR if you're interested.

All code in main is unofficial and unsupported. Code we'll be releasing from feature/track2 will be official but beta, so there should be no expectations to avoid breaking changes.

[heaths]

To summarize my read down the rabbit hole of comments e.g., #849 (comment), the gist is that we prefer http-types's enums over http's constants. That certainly improves the DX in a lot of ways.

[pront]

👋 Would you consider removing the dependency on http-crates completely? Last update was over 3y ago https://crates.io/crates/http-types/versions. This forces projects to keep old dependencies in their trees e.g. rand 0.7.3.

[pront]

Thank you for working on this! Do you plan to release a version that includes this refactoring anytime soon?

[heaths]

Our normal release cycle for Azure SDKs is the first full week of the month. We should be releasing a new beta then.

[pront]

One follow up here, do plan to release a new version for:

• https://crates.io/crates/azure_storage_blobs
• https://crates.io/crates/azure_storage

(since they still depend on the azure_core 0.21.0)

[heaths]

Those are not the correct crates. The Storage team decided to rename it to azure_storage_blob consistent with most other Azure SDK languages and the product name itself (singular).

/cc @vincenttran-msft

[vincenttran-msft]

@pront Hi Pavlos, here is the current, in-development Azure Storage Blob client library crate: https://crates.io/crates/azure_storage_blob

Please note that not all features may be implemented or work as intended currently. Thanks!

[pront]

@pront Hi Pavlos, here is the current, in-development Azure Storage Blob client library crate: https://crates.io/crates/azure_storage_blob

Please note that not all features may be implemented or work as intended currently. Thanks!

Interesting, this is what we depend on today:
https://github.com/vectordotdev/vector/blob/master/Cargo.toml#L258-L262

Do we have to replace the storage ones with https://crates.io/crates/azure_storage_blob?

Let me know if anything else stands out.
Thanks!