feature_request(configuration): configuration file

[Kristinita]

1. Summary

It would be nice if gh-release-install will support configuration file.

2. Justification of the need for the feature

When user run multiple gh-release-install commands for each operating system, configuration file brings significant amenities.

1. It would be nice to have the single configuration file for each operating system. Currently, users need to create 3 scripts for Linux, macOS and Windows.
2. DRY. Currently, user need to repeat command-line arguments in scripts.
3. Configuration files are more convenient to maintain. It’s easier for the user to make one change in the configuration file than to make multiple changes in scripts.

gh-release-install README starts that the project was mainly created to turn “mess” from Wget commands into the more simple and human-readable syntax. My proposal serves the same goal.

3. Example of desired behavior

3.1. Purpose

For example, I want to install in parallel to my Pipenv environment binaries from tidy-html5 and fd GitHub releases.

3.2. Current behavior MCVE

For Ubuntu and Windows I use scripts below:

1. github-releases-install.sh — the script for Ubuntu:

   #!/bin/bash
   gh-release-install Kristinita/tidy-html5 tidy .venv/bin --verbose &
   
   gh-release-install sharkdp/fd "fd-{tag}-x86_64-unknown-linux-gnu.tar.gz" --extract "fd-{tag}-x86_64-unknown-linux-gnu/fd" .venv/bin/fd --verbose &
   
   wait
   
   

   Travis CI demonstration how this script works.

2. github-releases-install.bat — the script for Windows:

   START /B CMD /C "gh-release-install Kristinita/tidy-html5 tidy.exe .venv/Scripts --verbose"
   
   START /B CMD /C "gh-release-install sharkdp/fd fd-{tag}-x86_64-pc-windows-gnu.zip --extract fd-{tag}-x86_64-pc-windows-gnu/fd.exe .venv/Scripts/fd.exe --verbose"
   
   

   AppVeyor CI demonstration how this script works.

3.3. Desired behavior

The file gh-release-install.yaml on the root of the project:

# [INFO] Equivalent of the “DESTINATION” positional argument
#
# [INFO] I use Pipenv workflow for my Python projects:
# https://pipenv.pypa.io/en/latest/
# Pipenv places binaries to the folder “.venv/bin” on UNIX operating systems
# and to the folder “.venv/Scripts” on Windows.
destination_path:

  # [INFO] If “linux_” and “macos_” keys has the same value, it would be nice to have the “unix_” prefix.
  # For example, “unix_path: .venv/bin” is equivalent to “linux_path: .venv/bin” + “macos_path: .venv/bin”
  unix_path: .venv/bin
  windows_path: .venv/Scripts


repositories:

  # [INFO] The release for the “tidy-html5” GitHub repository:
  # https://github.com/Kristinita/tidy-html5/releases/tag/5.9.20
  # The release contains solely binaries
  "Kristinita/tidy-html5":

    # [INFO] Save “tidy” binary to the “unix_path” directory on UNIX operating systems
    unix_binary: tidy

    # [INFO] Save “tidy.exe” binary to the “windows_path” directory on Windows
    windows_binary: tidy.exe


  # [INFO] Releases for the “fd” GitHub repository:
  # https://github.com/sharkdp/fd/releases
  # Releases contains archives
  "sharkdp/fd":
    linux_archive: fd-{tag}-x86_64-unknown-linux-gnu.tar.gz

    # [INFO] fd releases have different archives for Linux and macOS:
    # macos_arcihve: fd-{tag}-x86_64-apple-darwin.tar.gz

    # [INFO] Save the “fd” binary from “linux_archive” and “macos_archive” archives
    # to the “unix_path” directory on UNIX operating systems
    unix_binary: fd
    windows_archive: fd-{tag}-x86_64-pc-windows-gnu.zip

    # [INFO] Save the “fd.exe” binary from the “windows_archive” archive to the “windows_path” directory on Windows
    windows_binary: fd.exe


# [INFO] Equivalent of the “--verbose” command-line argument
verbose: true

Run the same command on both Ubuntu and Windows for getting the same behavior as for github-releases-install.sh and github-releases-install.bat:

gh-release-install install

4. Reply to the possible counterargument

4.1. “Your file "gh-release-install.yaml" has the problem "X". "Y" is better.”

OK, if that’s not a reason to say “we don’t need configuration file”.

In first, I’m interested in what the gh-release-install developers think about the very idea of a configuration file. The details how it will look can be discussed later in another issues.

Thanks.

[jooola]

Hey, Instead of maintaining a configuration file, I'd rather leave it to other tools that know how to do this.

You can use many tool to keep the details of the different tools, for example I have already used:

• Makefile
• ansible
• python script

import logging
from concurrent.futures import ThreadPoolExecutor, as_completed
from gh_release_install import GhReleaseInstall

tools = [
    GhReleaseInstall(
        repository="mvdan/sh",
        asset="shfmt_{tag}_linux_amd64",
        destination="./shfmt",
        version="v3.3.1",
    ),
    GhReleaseInstall(
        repository="prometheus/prometheus",
        asset="prometheus-{version}.linux-amd64.tar.gz",
        extract="prometheus-{version}.linux-amd64/prometheus",
        destination="./prometheus",
        version_file="{destination}.version",
        checksum="sha256:sha256sums.txt",
    ),
]

if __name__ == "__main__":
    logging.basicConfig(
        level=logging.INFO,
        format="%(levelname)s:\t%(message)s",
    )

    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = [executor.submit(i.run) for i in tools]

        for future in as_completed(futures):
            try:
                future.result()
            # pylint: disable=broad-except
            except Exception as exception:
                logging.exception(exception)

I don't have any long answer to your request this evening. But I feel uncomfortable reinventing the wheel.