http-client
http-client copied to clipboard
Disable default-features for http-types
http-client doesn't use any of the default features.
That isn't true, we re-export some things (e.g. Body) which as additional functions based on features, unfortunately.
I suspect we could change this without anyone noticing but we should probably be careful.
Good catch, thank you.
It looks like the main issue there would be things like Body::from_file, which needs the fs feature. Making http-client depend on the fs feature of http-types shouldn't be a problem; that only causes http-types to depend on async-std, which will often be a dependency of http-client anyway. So, I'll change this PR to enable the fs feature, which should then avoid breakage.
(In theory, someone could rely on http_client::http_types::cookie or similar, but that seems much less likely compared to just using http_types directly.)
@Fishrock123 Does this seem more reasonable? I think we can make this change without a semver-major bump.
Not sure what's causing the test failure. It looks like it happens on latest main, without this change; perhaps something changed elsewhere in the ecosystem that broke the http-client build.
EDIT: Ah, it's https://github.com/http-rs/tide/issues/787 .
@joshtriplett Could you rebase?
@Fishrock123 Done.
@joshtriplett If we release this, is cargo smart enough to not upgrade someone to this version if they are pinning to a previous http-types for some reason?
@Fishrock123 Cargo doesn't allow multiple compatible versions of the same crate in one dependency tree. If you're pinning an older http-types, you can't end up with a newer http-client that needs a newer http-types. (I don't know to what degree cargo's version resolution will decide to use an older http-client and to what degree it'll throw up its hands and say "nope, incompatible".)
Checking back on this: would it be possible to merge this to allow dropping cookie crates from projects that don't need them?
Bumping a major here likely means bumping a major in surf, which I'd like to avoid until I have to for http-types 3.0 if possible.
Is there a major milestone waiting to get to http-types 3.0? Similarly I'm trying to get rid of dependencies keeping things as light as possible and the latest http-types helps a bit changing the rand dependency that I wont be needing
@Fishrock123 As far as I can tell, now that this change no longer omits the fs feature, it shouldn't require bumping any major versions. Given that, would you consider this change for http-client?