The github v4 api is a little heavy for the github installer strategy in binny. Specifically a github token is required for use at all, and though the v3 api does not require this, it fetches a lot more information (is slower) and has pretty strict rate limiting. For this reason I've decided to add multiple strategies for fetching release information.
For installing, 3 strategies are attempted in the following order:
scrape the https://github.com/<user>/<repo>/releases/expanded_assets/<tag-or-latest> endpoint that drives the github UI. This is brittle, however, is the quickest way to get a list of all assets for a release universally. The risk is that GitHub may decide to change this endpoint at any time in the future for no reason or warning.
guess a variety of checksums.txt assets that may or may not be there, then use the contents for a listing of assets. This is not universally guaranteed and there are a few common patterns to try so it is not an ideal solution to use as a default.
use the v4 api as done today, which requires a token. (note: a better error message is now provided when there is no token available).
For updating the version locks, 2 strategies are attempted in the following order:
fetch the latest release tag from https://github.com/<user>/<repo>/releases/latest (accepting application/json)
use the v4 api as done today to get all releases, which requires a token.
For an update strategy to be deemed working, the result must not be empty and must also satisfy any user-given version constraint, otherwise the next strategy is attempted.
These updates will make binny not only faster but also not require a github token by default 🎉
The github v4 api is a little heavy for the github installer strategy in binny. Specifically a github token is required for use at all, and though the v3 api does not require this, it fetches a lot more information (is slower) and has pretty strict rate limiting. For this reason I've decided to add multiple strategies for fetching release information.
For installing, 3 strategies are attempted in the following order:
https://github.com/<user>/<repo>/releases/expanded_assets/<tag-or-latest>endpoint that drives the github UI. This is brittle, however, is the quickest way to get a list of all assets for a release universally. The risk is that GitHub may decide to change this endpoint at any time in the future for no reason or warning.checksums.txtassets that may or may not be there, then use the contents for a listing of assets. This is not universally guaranteed and there are a few common patterns to try so it is not an ideal solution to use as a default.For updating the version locks, 2 strategies are attempted in the following order:
https://github.com/<user>/<repo>/releases/latest(acceptingapplication/json)For an update strategy to be deemed working, the result must not be empty and must also satisfy any user-given version constraint, otherwise the next strategy is attempted.
These updates will make binny not only faster but also not require a github token by default 🎉