bin
bin copied to clipboard
Feature Request: support pre releases
Currently pre releases are filtered out by bin when checking for releases on Github.
The feature request is to provide an opt-in feature for the user to also use pre releases for install, ensure and update.
Followup to #84. Releated to #50.
Is this PR talking about github provider only? Shall we add a flag for this? Shall we warn the user that they're installing a pre-release? What happens if you have installed an actual release and the project pubishes a new pre-release? Does it make sense to update?
Is this PR talking about github provider only? Shall we add a flag for this? Shall we warn the user that they're installing a pre-release? What happens if you have installed an actual release and the project pubishes a new pre-release? Does it make sense to update?
@marcosnils The PR (#87) specifically handles GitHub, whose GetLatestRelease() method returns a 404 if there are only pre-releases. Once there is a regular release in the repo, you won't get a pre-release on bin update.
@marcosnils The PR (#87) specifically handles GitHub, whose
GetLatestRelease()method returns a 404 if there are only pre-releases. Once there is a regular release in the repo, you won't get a pre-release onbin update.
Gotcha, so the PR on #87 only works if the repo doesn't have any releases so far. I guess that's fair enough. What we need to keep discussing here is what happens there's a combination of release and pre-release. I guess that my previous questions apply to that case.
What we need to keep discussing here is what happens there's a combination of release and pre-release.
My personal preference would be to not automatically get newer pre-releases. However, I can see how some people who like to live on the bleeding edge might want to configure that for one or more binaries. A global option would likely lead to unwanted side-effects when you run bin update.
I would like to have the option on a per-binary base to opt-in for pre releases. E.g. something like this:
bin install --allow-pre-releases github.com/bufbuild/buf. The default would be false and the decision would be stored in the config file and therefore also affect bin update for the respective binaries.
bin install --allow-pre-releases github.com/bufbuild/buf
The "problem" with this is does pre-releases don't apply to all providers. I believe this should be a provider specific option since gitlab releases / packages and eventually other providers won't support this feature and --allow-pre-releases doesn't really make a lot of sense.
I understand. But so far we do not yet have a way in the cli API to distinguish between different flags for different providers. So what is your idea to make the cli flags provider dependend?
A way could be to allow each provider to "register" it self as a sub command.
With bin install github.com/marcosnils/bin, the code would try to find the right provider (based on the existing heuristic). With bin install github --allow-pre-releases marcosnils/bin we could allow provider specific flags.
I understand. But so far we do not yet have a way in the cli API to distinguish between different flags for different providers. So what is your idea to make the cli flags provider dependend
Each provider could still register it's own flags using a FlagSet with a prefix option. i.e bin install --github-allow-pre-releases <ur>. I think allowing each provider to register it's own flags is not a bad idea.
Any updates on this, I'm trying...
$ bin i github.com/0x192/universal-android-debloater
• Getting latest release for 0x192/universal-android-debloater
⨯ command failed error=repository 0x192/universal-android-debloater does not have releases
$ bin i --help
Installs the specified project from a url
Usage:
bin install <url> [flags]
Aliases:
install, i
Flags:
-a, --all Show all possible download options (skip scoring & filtering)
-f, --force Force the installation even if the file already exists
-h, --help help for install
-p, --provider string Forces to use a specific provider
Global Flags:
--debug Enable debug mode
I attempted a github-only solution at #178, does it make sense? if the repo doesn't have a latest release yet, we just use the latest pre-release. I like the proposed approach because the regular latest release reference takes precedence. as long as the repo has one, pre-releases are not considered