marcosnils / bin

Effortless binary manager
MIT License
682 stars 45 forks source link

Bug: Problem identifying correct release with multiple different releases #99

Open drzero42 opened 3 years ago

drzero42 commented 3 years ago

Scenario:

abo@ernest:~$ bin install github.com/kubernetes-sigs/kustomize
   • Getting latest release for kubernetes-sigs/kustomize
   ⨯ command failed            error=Could not find any compatible files
abo@ernest:~$ bin install https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv4.1.2
   • Getting kustomize/v4.1.2 release for kubernetes-sigs/kustomize
   • Starting download of https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.1.2/kustomize_v4.1.2_linux_amd64.tar.gz
4.97 MiB / 4.97 MiB [-------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% 5.74 MiB p/s 1s
   • Copying for kustomize@kustomize/v4.1.2 into /home/abo/.local/bin/kustomize
   • Done installing kustomize kustomize/v4.1.2
abo@ernest:~$ bin update kustomize
   • /home/abo/.local/bin/kustomize kustomize/v4.1.2 -> kyaml/v0.10.19 (https://github.com/kubernetes-sigs/kustomize/releases/tag/kyaml/v0.10.19)

So bin runs into problems when a repo releases multiple different things, which is fair I guess. Anything we can do to make it possible to install releases from such repos?

marcosnils commented 3 years ago

Anything we can do to make it possible to install releases from such repos?

This is going to be very tricky.. since if repo use any convention that they want it's going to be very difficult for us to be able to do something about it. I believe not even github thought about this use-case of one repository having multiple releases of multiple projects.

I saw this in the past but I've decided not to do so anything about it since it's the only case that I came across so far. If you have any simple way of fixing this I'm happy to hear options, but otherwise, I don't even think it's worth investing the time to fix this only case.

drzero42 commented 3 years ago

My first thought was that since the repo uses tagging that contains names of the releases (ie. kustomize and kyaml) we could allow setting a prefix for tags. That unfortunately probably won't work as the "latest release" only points to whatever was released last, switching between different products, so there won't always be a kustomize release marked as "latest release". Can bin figure out the latest version aside from what is marked as "latest release"?

marcosnils commented 3 years ago

Can bin figure out the latest version aside from what is marked as "latest release"?

Yes, we can do this since the GH releases API returns the releases ordered by date. The "problem" with this is that we'll have to supply some sort of prefix to bin install / update to let it know from which release we want to pick the binaries from. This is the part that I don't like for the following reasons:

  1. If we install things with bin install --prefix kustomize/ <repo_url> that means that bin will have to save the prefix in the config and use it on every update. If this is the case and the repo decides to use a different release name for whatever reason, then bin update will just break :(

  2. Based on 1, if we decide not to persist the prefix, then the UX around bin update will be completely broken as there will be some binaries which can't be updated.

I'd like to provide a "nice" alternative for this, but so far the only case where this has happened is the kustomize repo. Not sure if it makes sense to invest the time in fixing ATM.