Open speier opened 8 months ago
Hey! thx for the PR! retrieving binaries from direct http endpoints has been an idea that I've been waiting to generalize as a provider for a while and seems like this PR could be the perfect segway towards that. WDYT if we take this PR as a starting point and create a new http
provider that additionally allows receiving a --lastest-url
flag which basically takes care of this? I'd envision the UX something like
bin install --latest-url https://get.helm.sh/helm-latest-version https://get.helm.sh/helm-v3.13.1-linux-arm64.tar.gz
The idea is that bin
will store the latest-url
config and will use it for future bin update
runs.
How does that sound?
Hi! Yes, sounds good. I was also wondering how to have a generic approach.
I will update the PR.
Did you have a chance to take a look at the updated PR commits?
It's a brilliant idea to provide providers with the most popular tools like helm
, kubectl
! Always get sad about downloading and updating them manually.
Did you have a chance to take a look at the updated PR commits?
hey! my apologies for delaying on this one. Will check it out this week :pray:
hey @speier just found the time to start looking at this and it's looking great and in the right direction. The most relevant comment I have is that the provider doesn't seem to be generic. If I understood the code correctly, if you give it an URL with a shape different than https://get.helm.sh/helm-v3.13.1-linux-arm64.tar.gz, it'll just fail to parse it and error out.
Maybe I didn't explain my idea very well before ( apologies, not a native English speaker). My initial thought was to allow the generic provider to be able to fetch any kind of URL regardless of the format. So I could also do something like bin install https://some_url/some_file.tar.gz
and it'll also work. Optionally, this provider could receive a latest-url
argument that it'll use to check if there's a new version (initially, it could only check if the value is different to what's persisted in the config) and download the new file if this is the case.
LMK if that makes sense or if there's something you see I'm missing.
Thx again for contributing!
hey @speier just found the time to start looking at this and it's looking great and in the right direction. The most relevant comment I have is that the provider doesn't seem to be generic. If I understood the code correctly, if you give it an URL with a shape different than https://get.helm.sh/helm-v3.13.1-linux-arm64.tar.gz, it'll just fail to parse it and error out.
Maybe I didn't explain my idea very well before ( apologies, not a native English speaker). My initial thought was to allow the generic provider to be able to fetch any kind of URL regardless of the format. So I could also do something like
bin install https://some_url/some_file.tar.gz
and it'll also work. Optionally, this provider could receive alatest-url
argument that it'll use to check if there's a new version (initially, it could only check if the value is different to what's persisted in the config) and download the new file if this is the case.LMK if that makes sense or if there's something you see I'm missing.
Thx again for contributing!
Hi! The idea was to use a somewhat standard naming convention: name-version-os-arch.ext
otherwise not sure how it could work, if the url doesn't contain version/os/arch. Maybe I miss something here, but happy to discuss your ideas. Thx!
Started as a Helm provider, trying to turn into a generic provider, see comments below.
~Provider to download Helm releases from https://get.helm.sh~
~Supports getting latest version from https://get.helm.sh/helm-latest-version or fetching specified version.~
~Unfortunately Helm using a rather strange way for their releases and they don't provide a list of release builds for OS/Arch, so we need to maintain a list of possible architecture and OS versions in the provider.~