jqnatividad/qsv: Expect single binary file got more or less: []
I expect the qsv binary to be installed when I run the following command. Instead I get an error.
$ install-release get https://github.com/jqnatividad/qsv -n qsv -y -v
DEBUG Token not set core.py:59
DEBUG /home/isme/.config/install_release/state.json cli_interact.py:63
DEBUG /home/isme/.config/install_release/config.json cli_interact.py:64
DEBUG /home/isme/bin cli_interact.py:65
DEBUG get: https://api.github.com/repos/jqnatividad/qsv/releases/latest core.py:89
DEBUG Token not set core.py:59
DEBUG ('platform_words: ', ['linux', '64bit', 'x86', 'x64', 'amd64', 'amd', 'x86_64', core.py:169
'(.tar|.zip)'])
DEBUG name: 'qsv-0.93.1-aarch64-apple-darwin.zip', chances: 0.2222222222222222 core.py:190
DEBUG name: 'qsv-0.93.1-aarch64-unknown-linux-gnu.zip', chances: 0.3333333333333333 core.py:190
DEBUG name: 'qsv-0.93.1-i686-pc-windows-msvc.zip', chances: 0.2222222222222222 core.py:190
DEBUG name: 'qsv-0.93.1-i686-unknown-linux-gnu.zip', chances: 0.3333333333333333 core.py:190
DEBUG name: 'qsv-0.93.1-x86_64-apple-darwin.zip', chances: 0.4444444444444444 core.py:190
DEBUG name: 'qsv-0.93.1-x86_64-pc-windows-gnu.zip', chances: 0.4444444444444444 core.py:190
DEBUG name: 'qsv-0.93.1-x86_64-pc-windows-msvc.zip', chances: 0.4444444444444444 core.py:190
DEBUG name: 'qsv-0.93.1-x86_64-unknown-linux-gnu.zip', chances: 0.5555555555555556 core.py:190
DEBUG name: 'qsv-0.93.1-x86_64-unknown-linux-musl.zip', chances: 0.5555555555555556 core.py:190
DEBUG Selected file: core.py:207
File: 'qsv-0.93.1-x86_64-unknown-linux-gnu.zip', content_type:
'binary/octet-stream', chances: 0.5555555555555556
DEBUG GithubReleaseAssets(browser_download_url='https://github.com/jqnatividad/qsv cli_interact.py:92
/releases/download/0.93.1/qsv-0.93.1-x86_64-unknown-linux-gnu.zip',
content_type='binary/octet-stream', created_at='2023-03-15T16:56:55Z',
download_count=10, id=99525781,
name='qsv-0.93.1-x86_64-unknown-linux-gnu.zip',
node_id='RA_kwDOExnjV84F7qSV', size=44468179, state='uploaded',
updated_at='2023-03-15T16:56:57Z')
DEBUG Download path: /tmp/dn_qsv_z578xayk core.py:220
INFO Downloaded: 'qsv-0.93.1-x86_64-unknown-linux-gnu.zip' at /tmp/dn_qsv_z578xayk utils.py:187
DEBUG path: /tmp/dn_qsv_z578xayk/qsv-0.93.1-x86_64-unknown-linux-gnu.zip core.py:223
DEBUG Extracting: /tmp/dn_qsv_z578xayk/qsv-0.93.1-x86_64-unknown-linux-gnu.zip core.py:225
DEBUG Extracting done. core.py:230
ERROR Expect single binary file got more or less: core.py:248
[]
The release archive qsv-0.93.1-x86_64-unknown-linux-gnu.zip contains many files. I even tried using the -n switch to tell install-release to install just the qsv binary, but it hasn't helped.
The archive contains the following files:
$ unzip -l qsv-0.93.1-i686-unknown-linux-gnu.zip
Archive: qsv-0.93.1-i686-unknown-linux-gnu.zip
Length Date Time Name
--------- ---------- ----- ----
1114 2023-03-15 15:30 README
19827688 2023-03-15 15:30 qsv
8263792 2023-03-15 15:30 qsvdp
8951920 2023-03-15 15:30 qsvlite
--------- -------
37044514 4 files
My OS is Ubuntu 20.04.5 LTS.
How do install qsv using install-release?
(Thanks for the awesome tool, by the way. It's much more convenient that writing a custom install script for every single GitHub-hosted tool.)
there are more than one binary files present in release thats why it's unable to install it.
I thought that might be the case.
To support a use case like this, would you consider:
- adding an extra option to specify the single binary to extract? (In my case, I would specify
qsvas the value) - extracting all the binaries by default (I can just ignore the binaries
qsvliteandqsvdpor even delete them later)
Also, is there any option in install-release to override the automatic detection platform words?
For now I've installed the tool using a custom script.
In my custom script I choose the "musl" version because the "gnu" version depends on a version of glibc that I don't have.
I tried the "gnu" version but qsv on Ubuntu 20.04 fails to execute with the following error:
./qsv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./qsv)
./qsv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./qsv)
./qsv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./qsv)
./qsv: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./qsv)
I have GLIBC version 2.31 here, which apparently is not favored.
In other words, it would be awesome if get-release had syntax like this to cover my use case:
install-release get https://github.com/jqnatividad/qsv \
--extract-binary qsv \
--platform-hint musl
thats ok while installing but what about upgrade part
I'm not sure, to be honest. I haven't used the upgrade command yet!
Without keeping track of the parameters used to install a tool in the first place, it's likely to fail on a special case like this.
I think I'd be fine with that. I would just upgrade each tool individually.
I suppose it's always a risk since any tool can change its release format arbitrarily.
I just noticed that there is also a state subcommand that stores metadata about each installed tool. If that metadata included enough to reconstruct the install command with all its extra parameters, then maybe it could be used to make a more robust upgrade process.
Not sure though. Up to you whether you want to add that extra complexity or not.
If not, I would just keep using install-release when it works and write custom scripts for the more complex cases.
arbitrarily
yes that's the issue for zip having more than 1 binary :)
gh release-install provides a solution in this case.
gh-release-install \
--extract "qsv" \
"jqnatividad/qsv" \
"qsv-{tag}-x86_64-unknown-linux-musl.zip" \
"${HOME}/.local/bin/qsv"
It works, but it's the syntax isn't memorable like install-release's. :-)
Just FYI, its not unique to qsv, https://github.com/dandavison/delta also has the same issue. It has three files delta (binary), LICENSE (text) and README.md (text). Confused how those other 2 files are being seen as binary. The files are inside a directory, so Is it expected that the executable would be found in the root of the tar.gz file? Specific to this binary, it would be helpful to have some way to influence the name of the release file to download. Since the version I want to download is delta-0.15.1-x86_64-unknown-linux-musl.tar.gz, if the user could add in some platform_words like musl this would help bump the values and get the correct version. Again these changes would need to be held in the state file for use at upgrade time.
$ install-release get -n delta https://github.com/dandavison/delta -y -v
DEBUG Token not set core.py:59
DEBUG /home/paulmansfield/.config/install_release/state.json cli_interact.py:63
DEBUG /home/paulmansfield/.config/install_release/config.json cli_interact.py:64
DEBUG ~/.local/bin cli_interact.py:65
DEBUG get: https://api.github.com/repos/dandavison/delta/releases/latest core.py:89
DEBUG Token not set core.py:59
DEBUG ('platform_words: ', ['linux', '64bit', 'x86', 'x64', 'amd64', 'amd', 'x86_64', '(.tar|.zip)']) core.py:169
DEBUG name: 'delta-0.15.1-aarch64-apple-darwin.tar.gz', chances: 0.2222222222222222 core.py:190
DEBUG name: 'delta-0.15.1-aarch64-unknown-linux-gnu.tar.gz', chances: 0.3333333333333333 core.py:190
DEBUG name: 'delta-0.15.1-arm-unknown-linux-gnueabihf.tar.gz', chances: 0.3333333333333333 core.py:190
DEBUG name: 'delta-0.15.1-i686-unknown-linux-gnu.tar.gz', chances: 0.3333333333333333 core.py:190
DEBUG name: 'delta-0.15.1-x86_64-apple-darwin.tar.gz', chances: 0.4444444444444444 core.py:190
DEBUG name: 'delta-0.15.1-x86_64-pc-windows-msvc.zip', chances: 0.4444444444444444 core.py:190
DEBUG name: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz', chances: 0.5555555555555556 core.py:190
DEBUG name: 'delta-0.15.1-x86_64-unknown-linux-musl.tar.gz', chances: 0.5555555555555556 core.py:190
DEBUG name: 'git-delta-musl_0.15.1_amd64.deb', chances: 0.3333333333333333 core.py:190
DEBUG name: 'git-delta_0.15.1_amd64.deb', chances: 0.3333333333333333 core.py:190
DEBUG name: 'git-delta_0.15.1_arm64.deb', chances: 0.1111111111111111 core.py:190
DEBUG name: 'git-delta_0.15.1_armhf.deb', chances: 0.1111111111111111 core.py:190
DEBUG name: 'git-delta_0.15.1_i386.deb', chances: 0.1111111111111111 core.py:190
DEBUG Selected file: core.py:207
File: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz', content_type: 'application/gzip', chances: 0.5555555555555556
DEBUG GithubReleaseAssets(browser_download_url='https://github.com/dandavison/delta/releases/download/0.15.1/delta- cli_interact.py:92
0.15.1-x86_64-unknown-linux-gnu.tar.gz', content_type='application/gzip', created_at='2022-12-03T20:29:17Z',
download_count=5892, id=86891932, name='delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz',
node_id='RA_kwDOC4j8g84FLd2c', size=2782183, state='uploaded', updated_at='2022-12-03T20:29:17Z')
DEBUG Download path: /tmp/dn_delta_ctw5g0vl core.py:220
INFO Downloaded: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz' at /tmp/dn_delta_ctw5g0vl utils.py:187
DEBUG path: /tmp/dn_delta_ctw5g0vl/delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz core.py:223
DEBUG Extracting: /tmp/dn_delta_ctw5g0vl/delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz core.py:225
DEBUG Extracting done. core.py:230
ERROR Expect single binary file got more or less: core.py:248
[]
As you can see there is a directory in the tar.gz file:
$ tar tvfz delta-0.15.1-x86_64-unknown-linux-musl.tar.gz
-rw-r--r-- runner/docker 1051 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/LICENSE
-rw-r--r-- runner/docker 6861 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/README.md
-rwxr-xr-x runner/docker 6006152 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/delta
Just FYI, its not unique to qsv, https://github.com/dandavison/delta also has the same issue. It has three files delta (binary), LICENSE (text) and README.md (text). Confused how those other 2 files are being seen as binary. The files are inside a directory, so Is it expected that the executable would be found in the root of the tar.gz file? Specific to this binary, it would be helpful to have some way to influence the name of the release file to download. Since the version I want to download is delta-0.15.1-x86_64-unknown-linux-musl.tar.gz, if the user could add in some platform_words like musl this would help bump the values and get the correct version. Again these changes would need to be held in the state file for use at upgrade time.
$ install-release get -n delta https://github.com/dandavison/delta -y -v DEBUG Token not set core.py:59 DEBUG /home/paulmansfield/.config/install_release/state.json cli_interact.py:63 DEBUG /home/paulmansfield/.config/install_release/config.json cli_interact.py:64 DEBUG ~/.local/bin cli_interact.py:65 DEBUG get: https://api.github.com/repos/dandavison/delta/releases/latest core.py:89 DEBUG Token not set core.py:59 DEBUG ('platform_words: ', ['linux', '64bit', 'x86', 'x64', 'amd64', 'amd', 'x86_64', '(.tar|.zip)']) core.py:169 DEBUG name: 'delta-0.15.1-aarch64-apple-darwin.tar.gz', chances: 0.2222222222222222 core.py:190 DEBUG name: 'delta-0.15.1-aarch64-unknown-linux-gnu.tar.gz', chances: 0.3333333333333333 core.py:190 DEBUG name: 'delta-0.15.1-arm-unknown-linux-gnueabihf.tar.gz', chances: 0.3333333333333333 core.py:190 DEBUG name: 'delta-0.15.1-i686-unknown-linux-gnu.tar.gz', chances: 0.3333333333333333 core.py:190 DEBUG name: 'delta-0.15.1-x86_64-apple-darwin.tar.gz', chances: 0.4444444444444444 core.py:190 DEBUG name: 'delta-0.15.1-x86_64-pc-windows-msvc.zip', chances: 0.4444444444444444 core.py:190 DEBUG name: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz', chances: 0.5555555555555556 core.py:190 DEBUG name: 'delta-0.15.1-x86_64-unknown-linux-musl.tar.gz', chances: 0.5555555555555556 core.py:190 DEBUG name: 'git-delta-musl_0.15.1_amd64.deb', chances: 0.3333333333333333 core.py:190 DEBUG name: 'git-delta_0.15.1_amd64.deb', chances: 0.3333333333333333 core.py:190 DEBUG name: 'git-delta_0.15.1_arm64.deb', chances: 0.1111111111111111 core.py:190 DEBUG name: 'git-delta_0.15.1_armhf.deb', chances: 0.1111111111111111 core.py:190 DEBUG name: 'git-delta_0.15.1_i386.deb', chances: 0.1111111111111111 core.py:190 DEBUG Selected file: core.py:207 File: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz', content_type: 'application/gzip', chances: 0.5555555555555556 DEBUG GithubReleaseAssets(browser_download_url='https://github.com/dandavison/delta/releases/download/0.15.1/delta- cli_interact.py:92 0.15.1-x86_64-unknown-linux-gnu.tar.gz', content_type='application/gzip', created_at='2022-12-03T20:29:17Z', download_count=5892, id=86891932, name='delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz', node_id='RA_kwDOC4j8g84FLd2c', size=2782183, state='uploaded', updated_at='2022-12-03T20:29:17Z') DEBUG Download path: /tmp/dn_delta_ctw5g0vl core.py:220 INFO Downloaded: 'delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz' at /tmp/dn_delta_ctw5g0vl utils.py:187 DEBUG path: /tmp/dn_delta_ctw5g0vl/delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz core.py:223 DEBUG Extracting: /tmp/dn_delta_ctw5g0vl/delta-0.15.1-x86_64-unknown-linux-gnu.tar.gz core.py:225 DEBUG Extracting done. core.py:230 ERROR Expect single binary file got more or less: core.py:248 []As you can see there is a directory in the tar.gz file:
$ tar tvfz delta-0.15.1-x86_64-unknown-linux-musl.tar.gz -rw-r--r-- runner/docker 1051 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/LICENSE -rw-r--r-- runner/docker 6861 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/README.md -rwxr-xr-x runner/docker 6006152 2022-12-03 20:32 delta-0.15.1-x86_64-unknown-linux-musl/delta
Can you try again after updating install-release i tried installing https://github.com/dandavison/delta an was able to install it.
I can confirm that on my home system (debian testing) it installs the gnu version fine now. However, I still have a requirement to install the musl version on older LTS distributions. Seeing that platform_words is used to score the release files, I do think that being able to add to that would fix this and perhaps more issues.
I do see that adding that a user_platform_words into the state file is required for upgrades. I also see that if you need to update that user_platform_words could be done by running install again with the new user_platform_words which would update the state file with the new platform_words so updates would use the latest.