Feature Request: EXTRACT ALL option for archive (zip/tar/gz/etc) releases

[ZacWolf]

trafficstars

Currently, if a release is in the form of an archive, Bin just lists all the files in the archive and prompts for which (single) file you wish to extract.

I would like to submit a pull request to implement a choice zero (extract all) when a release is an archive file (zip/tar/etc).

Looks like that is handled in: /pkg/assets/assets.go:343-353?

To implement an "Option 0" I would also like to propose the following change to /options/options.go

func SelectWithOptionZero(msg string, optzero string, opts []fmt.Stringer) (interface{}, error){}

…vs going down the interface{} route to "overload" the existing Select function. Just easier for backwards compatibility.

Thoughts?

[breml]

I like the idea to extract all files from a given archive. My question is, what would be the location, where the archive gets extracted.

Before I discovered bin, I started to implement something similar. In my tool I used three different folders:

1. a cache dir, where I kept the downloaded archives (this is not strictly necessary), for this I used a sub directory in the folder returned from os.UserCacheDir() by default.
2. a share dir, where I extracted the downloaded archives, for this I used a sub directory in path.Join(os.UserHomeDir(), ".local", "share", "<tool name>"). Every archive go extracted into its own directory, composed from the name of the tool (binary) and the version.
3. Instead of copying the binary to the bin-dir (in my case path.Join(os.UserHomeDir(), "bin"), I decided to symlink the binary file in the share dir to the bin dir.

Just my 2 cts.

[ZacWolf]

This is my understanding so far about what Bin does:

1. Bin currently reads the "source" file into memory, so there is no file-based-caching of the source download

2. Bin already takes a parameter that is used as the "install directory", so the unarchived files would be sent there (or if that parameter isn't provided, to the default directory that is selected the first time Bin is run) eg: bin install github.com/marcosnils/bin D:\install\dir Will install the executable to the directory: D:\install\dir

3. This sounds like you're not providing the [install directory] parameter, so all of your "installs" are being directed to the bin directory that was set the very first-time Bin was run. (if you rename ~/.bin/config.json and re-run Bin then it will prompt you for the "default" install location, just remember to delete the new config.json generated and replace your original file, or bin will lose track of all your current installs).

In another post (#54) I've requested to move the "install directory" parameter into a flagged parameter (--installdir=). Basically, using the Cobra addon paradigm of all "optional" values being provided via flagged parameters, and then using any non-flagged argument in-place of any input that would otherwise come from stdin. This would break some backwards compatibility, so I've asked the dev if they have any idea of the impact of moving the current 3rd argument (install directory) to a flagged parameter instead.

[sirlatrom]

I will let @marcosnils decide on this matter, but my impression from the README.md is that bin is centered around "the popularity of single binary releases due to the surge of languages like Go, Rust, Deno, etc which can easily produce dynamically and statically compiled binarines."

Supporting multiple files, dependencies, etc. sounds like a wider/different scope. What do you think, @marcosnils?

[breml]

@sirlatrom I agree with you, that supporting dependencies would be a completely different beast to tackle. But extracting all files from an release archive to a target folder instead of just extracting the binary wouldn't be difficult. This could easily be done by an additional step, when the archive is extracted in memory and it could be controlled by a flag.

As mentioned also in #71, sometimes the binary is not everything that is needed, because there might be other files, that are used together with the binary (e.g. templates, config files, etc.). There is also the question around the license. Some open source licenses require the binary to be shipped with the license. In this case it might even be a violation of the license to only extract the binary.

[breml]

Just to give an example, installing cue with bin install github.com/cuelang/cue misses a lot of valuable documentation.

[sirlatrom]

Just to give an example, installing cue with bin install github.com/cuelang/cue misses a lot of valuable documentation.

@breml I can see that getting that content extracted somewhere would be valuable, but what when you install the next tool that also has a doc sub-directory in the release asset archive?

So far, bin has only managed individual binaries with one file in a target location per source, with the result that the binary you've downloaded ends up in your $PATH.

[breml]

@sirlatrom My idea is to extract the archives e.g. into ~/.local/share/bin/<binary-name>-<version>. In the tool I started coding I then linked the binary to e.g. ~/bin, so this file is not stored twice on disk. Of course, for Windows we would need to workaround this.

For now, bin does not really care about versions, so the content of the archive could be extracted to ~/.local/share/bin/<binary-name>. Whenever an update for a binary happens, the complete folder would be removed an recreated with the content of the new archive.

[edshamis]

It would be lovely if this could be implemented. It happened to me yesterday that I wanted to install some release with multiple files in zip archive. If bin could handle this kind of releases I would be assured that that they continue to be tracked for updated.