marcosnils
Generic provider
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.~
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.
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.gzand it'll also work. Optionally, this provider could receive alatest-urlargument 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!