Replacing `hyperx`'s header parsing

[b-NC]

Hi,

I am trying to use this crate in my project alongside rocket-rs, only there seems to be an issue with the dependencies

stdout :     Updating crates.io index
error: failed to select a version for `httparse`.
    ... required by package `hyperx v1.3.0`
    ... which satisfies dependency `hyperx = "^1.3.0"` of package `octocrab v0.12.0`
    ... which satisfies dependency `octocrab = "^0.12.0"` of package `version-summarizer v0.1.0 (/home/infrandomness/Documents/Dev/Rust/version-summarizer)`
versions that meet the requirements `>=1.0, <1.4` are: 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0, 1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.2, 1.1.1, 1.1.0, 1.0.0

all possible versions conflict with previously selected packages.

  previously selected package `httparse v1.4.0`
    ... which satisfies dependency `httparse = "^1.4"` of package `hyper v0.14.9`
    ... which satisfies dependency `hyper = "^0.14.2"` of package `hyper-tls v0.5.0`
    ... which satisfies dependency `hyper-tls = "^0.5"` of package `reqwest v0.11.4`
    ... which satisfies dependency `reqwest = "^0.11.3"` of package `octocrab v0.12.0`
    ... which satisfies dependency `octocrab = "^0.12.0"` of package `version-summarizer v0.1.0 (/home/infrandomness/Documents/Dev/Rust/version-summarizer)`

failed to select a version for `httparse` which could resolve this conflict

This happens when I have both rocket (latest version as of today) and octocrab

[XAMPPRocky]

Thank you for your issue! I'm aware of the incompatibility, however until headers or an equivalent is more fully developed and can actually replace the hyperx's functionality in octocrab (which requires safe and correct handling of ETag, If-None-Match, and Link headers), I'd prefer to keep it.

[alarsyo]

Hi! I'm hitting a similar problem.

For my use case at least, it turns out the fix would be quite simple: I'm writing a webhook server, so I'm only using octocrab for its models, for deserialization of webhook payloads.

Would you consider splitting this part into an octocrab_models crate that wouldn't depend on hyperx (I don't think this part needs it, correct me if I'm wrong!) ?

[alarsyo]

I can write a PR, if it's something you'd consider, but don't have any time for right now 😄

[alarsyo]

This has the side benefit of not having to build reqwest and other dependencies when only using the models in some tool

[XAMPPRocky]

Would you consider splitting this part into an octocrab_models crate that wouldn't depend on hyperx (I don't think this part needs it, correct me if I'm wrong!) ?

I don't want to split crates, as that would be extra maintenance. I like to release after every change if possible at the moment.

This has the side benefit of not having to build reqwest and other dependencies when only using the models in some tool

I'd prefer to provide this as a main benefit to octocrab itself by removing reqwest entirely. See #99

[alarsyo]

I'd prefer to provide this as a main benefit to octocrab itself by removing reqwest entirely. See #99

That makes sense.

I'm aware of the incompatibility, however until headers or an equivalent is more fully developed and can actually replace the hyperx's functionality in octocrab (which requires safe and correct handling of ETag, If-None-Match, and Link headers), I'd prefer to keep it.

From the headers you mention, it seems like headers only lacks support for Link currently, and there's a PR for it. Hopefully that allows stripping the hyperx dependency soon enough

[chinedufn]

I'm in a similar boat here where using octocrab is preventing me from using another crate.

Personally, I think that is it better for the Rust ecosystem to have a separate crate with just the models, then octocrab would depend on that.
And then others could use it directly if they didn't want octocrab's request logic.

But, I understand the point about the extra maintenance. Although I suspect that for a crate that should very rarely change once it's "done" (all current GitHub APIs are supported), the maintenance burden would be negligible. Assuming the crate lived in the same Cargo workspace.

---

Anyway.. The PR that @alarsyo linked looks stale. So I'm not banking on only using headers being ready anytime soon.

Could we simply copy Link from hyperx into a mod temp_hyperx?
In principle this type should never change, so I think vendoring it is fine and won't introduce any additional maintenance burden.

1. Octocrab starts working for everyone again

2. No real maintenance burden since the hyperx types shouldn't ever need to change

3. When headers is ready we just delete the temp_hyperx module.

Downside is a some gunk in the crate, but I think that's better than the crate simply not working for people.

[XAMPPRocky]

Anyway.. The PR that @alarsyo linked looks stale. So I'm not banking on headers being ready anytime soon.

Someone opened a new PR adding the Link header back yesterday. Good things come to those who wait. 🙂 hyperium/headers#91 So I'm going to track the progress of that PR before vendoring the code into octocrab.

I understand your frustration, however it's not fair characterisation that incompatibility with a certain framework version is "not working for everyone". Cargo has great support for git dependencies if you need it for your project sooner.

[chinedufn]

I'm don't use Rocket so it isn't just Rocket.

But I'm very sorry. Instead of "everyone" I should have said "people who have httpparse >1.4 in their dependency tree

I didn't mean to come off in the way that I did. I was just trying to explain my thought process and make a case for why I thought we should consider vendoring.
I should have been more conscious of how that might sound.

I'm sorry!

[lpotthast]

Hi, it also doesn't work when using axum:

error: failed to select a version for `percent-encoding`.
    ... required by package `hyperx v1.3.0`
    ... which satisfies dependency `hyperx = "^1.3.0"` of package `octocrab v0.17.0`
    
versions that meet the requirements `>=2.1.0, <2.2` are: 2.1.0

all possible versions conflict with previously selected packages.

  previously selected package `percent-encoding v2.2.0`
    ... which satisfies dependency `percent-encoding = "^2.1"` of package `axum v0.5.16`

Kind of a deal-breaker for me sadly... I hope this can be fixed in the future. Great work btw 👍