search

exercism / v2-configlet

Tool to assist in managing Exercism language tracks.
MIT License
16 stars 23 forks source link

fetch-configlet.sh: Fetch the latest release url from the Github API #161

Closed ZapAnton closed 3 years ago

ZapAnton commented 5 years ago

This PR changes the approach the URL for the latest release of configlet is built. Before the PR: Manually build the URL using the version from the HTTP header. After the PR: Get the full URL from the Github API. IMHO this approach is more reliable.

SleeplessByte commented 5 years ago

How exactly is it more reliable?

ZapAnton commented 5 years ago

By moving from manually building the URL, which may be error-prone if the script is further expanded, to making the Github build the URL for us making it the single source of truth. Plus parsing the header of the HTTP response header seems a bit awkward - can you guarantee that the header structure will not change between the calls? The same could be asked about the Github API, but I have an impression that the returned JSON is still more stable than a header.

SleeplessByte commented 5 years ago

Can you guarantee that the header structure will not change between the calls?

Since GitHub is using REST urls, I think it's equally unlikely for the URL to latest to change as the API to change. The header is the Location header, which structure has been the same, at least since 1999, a header which your browser actually relies on to redirect you to the next page (which is what happens if you browse to https://github.com/exercism/configlet/releases/latest).

If you're asking if we can guarantee if the value of that header will always be actually the latest version (i.e. redirect to tag/latest-version); the answer to that is "about as well as a guarantee the API will not change".

The same could be asked about the Github API, but I have an impression that the returned JSON is still more stable than a header.

I think there is no proof to support that impression.

Note that in both cases we're completely relying on the author of the tag to:

and in both cases we're looking for the correct url; right now by building it, or after this PR by searching for it. Both will fail if the tag author has failed.

I personally don't feel this is an improvement to the script (but also not a declination). The pro for your change would be that you're only making 1 request instead of 2; which ís somewhat favourable.