Support direct binary (non-archive) downloads about krew

[lbb]

We choose ZIP, as it is the default format GitHub offers to download (although tar.gz is also available).

If we choose to offer different download formats we should not use different classifiers to specify an URI. We should focus on MIME types as UNIX does it. We also should fall back to files post-fixes.

[ahmetb]

We choose ZIP, as it is the default format GitHub offers to download

This is not a good argument and only works for python/bash scripts etc. Not to mention, github supports .tar.gz, too?

we should not use different classifiers
We also should fall back to files post-fixes.
We should focus on MIME types as UNIX does it.

All these 3 are basically just "do not be verbose and employ magic", which I'm against.

Good software rarely tries to guess things (esp. from stuff like mime types or extensions).

[lbb]

1. In case we want to be explicit by writing the filetype of the resource at the URI:
   If we do so, we should not make it a field in the plugin spec like file: https://.., archive: https://.... Adding fields is not flexible:

• We have to add a new field for every compression type. -> It's a spec version bump on every new field.
• Developers can declare multiple URI's at once.

I propose to add a new text field downloadType which specifies the download format.

2. We only have a few types we want to support (.tar, tar.gz, zip and plain). All of
   those types are identifiable by a magic number that is part of it's standard.
   MIME detection is not magic; it's just detecting the file header bytes.

I'm not for employing magic. We know what type it is after we have downloaded it. We are not guessing.

[ahmetb]

Yeah that mostly makes sense.

We could easily add validation to support multiple fields. I suspect if we receive this request again, we need to go implement something simple (like detecting file extension).

[lbb]

/fixes #34
/cc @robscott

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ahmetb]

I'm not sure if there’s enough demand for it currently.
/close

[k8s-ci-robot]

@ahmetb: Closing this issue.

In response to this:

I'm not sure if there’s enough demand for it currently.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.