add protobuf parsing for binary

[benev0]

split parse_repository_v2_versions off of get_repository_versions_response, and split parse_repository_v2_package off of get_package_response

The new functions do the same protobuf parsing as the ..._response functions but start from binary rather than a response allowing protobuf messages to be stored and parsed at different times.

required by gleam-lang/gleam#2162

[lpil]

Hello! Could you expand a bit on what these are used for? Thank you 🙏

Don't we also need functions to download this data? Where does it come from?

We'll also need documentation and tests for any new functions.

[benev0]

Hello! Could you expand a bit on what these are used for? Thank you 🙏

These are functions to parse protobuf messages from the binary format. These are used in the case that a request is not made so a response is not available. For example reading from a message cache.

Don't we also need functions to download this data? Where does it come from?

It is my understanding that hexpm-rust does not handle downloading data and making http requests, so procuring the data is the responsibility of library consumers.

v1.4.0 - 2021-11-25

• The HTTP client has been removed from this library in favor of request
  building and response parsing functions. Bring your own HTTP client of choice.

CHANGELOG.md

In the case of gleam-lang/gleam#2162 the body of successful response is cached. Parsing only signed messages should prevent any shenanigans with the protobuf apis.

[benev0]

I believe I have covered raised issues, and am ready for any new ones.

[lpil]

It is my understanding that hexpm-rust does not handle downloading data and making http requests, so procuring the data is the responsibility of library consumers.

No, but we do expose functions for constructing the HTTP requests, as you can see from the functions for working with the Hex API.

I think the plan is to use these with the protobuf index files that can be downloaded from the Hex repo (sounds great!), so let's add a function for constructing the requests to download these files. Matching functions that decode the response would be fab too, checking the HTTP status, and parsing the body.

[benev0]

... let's add a function for constructing the requests to download these files.

Currently get_repository_versions_request and get_package_request do exactly this.

Matching functions that decode the response would be fab too, checking the HTTP status, and parsing the body.

Ditto: get_repository_versions_response and get_package_response.

I think I may have misunderstood. Could you provide some clarification?

Do you mean check 200 then decompress? I.E. Request<Vec<u8>> -> Vec<u8>.

[lpil]

Apologies, I got confused with my previous comments, I thought that the existing functions used the API and not the registry. This looks great!

[benev0]

All good I could have been clearer. Thank you for the help particularly with discarding #47, that was a mess.