comtrya
GitHub Binary - Support Archives
Description
binary.github can download a binary from a GitHub release, but we don't support archives (tar.gz). We should unarchive these and stick the binaries into the directory
Would the directory be a user specified directory?
Yea. The direction is mandatory in the spec
For the most part, this seems straight forward except for one thing. Pulling a binary is easy. On Unix platforms (BSD, Linux, MacOS), tar should be available so calling tar or gunzip isn't much of an issue for a command step. However, I don't think Windows has the tar programs apart of the base system.
I did take a look at Rust crates. Many of them can read, but don't do any kind of compression work or decompression work.
7zip can deal with most of that - and looking at package managers on windows (scoop.sh for example), this is their approach. Can (or maybe the question is "should?") comtrya have a configuration testing for 7zip dependency on a windows machine for these binaries?
With which, we can check to see if 7zip is in the path. The question here is, should we build in that we pull 7zip from winget if not present or bubble up a warning to the user and stop exeuction of that code path?
I think this depends on the way chosen to support this, and how complex of a solution do you want to introduce. I can think of a whole bunch of 'complications' to the code base that can come in here - just not sure what would strike the correct balance in this case:
- default behavior would rely on the existence of a specific extractor in path (7z.exe on windows, tar in linux, etc.)
- comtrya could allow a choice of specifying an external extractor command line (making this more system agnostic, with sensible defaults per system)
- It could allow this to be defined per file-type/extension
- When extraction is required, test for existence of the extractor executable and prompt if it's missing (maybe with a hint of what to add as a depends on deployment tip.
So looking at the source tree. Perhaps we should also rename the src/lib/src/actions/binary to src/lib/src/actions/github and rename the current github.rs file to binary.rs?
Well I guess it comes down to a greater question. When we pull down archived files, is it right to assume they are binaries? Someone could also be pulling down just the archived source with the same functionality.
I like the download.archive. If a link is being provided in the yaml, the logic we could make should work even if the download occurs from somewhere other than github.
I've recently stumbled over this issue and i'm wondering if it's still a valid feature request? As @martintc already implemented two (closed) working implementations for that issue i'm curious why they got closed without merging.
I'm happy to implement that feature if no one is working on that right now (but TBH: i've never done that much with rust - go is my preferred language :sweat_smile: )
I've recently stumbled over this issue and i'm wondering if it's still a valid feature request? As @martintc already implemented two (closed) working implementations for that issue i'm curious why they got closed without merging.
I'm happy to implement that feature if no one is working on that right now (but TBH: i've never done that much with
rust-gois my preferred language 😅 )
I may have closed this one accidentally when grooming the issues. Apologies for that.
I did merge in about a month ago the atom for supporting unarchiving tar files and I am working on implementing the action. Then after that, I will take a look at how to include that into finalizers and then the unarchiving part should be done.