DEV Community: TekWizely

Running Your BATS Tests Against Multiple Bash Versions in GitHub

TekWizely — Fri, 12 Nov 2021 22:50:11 +0000

In this post I'll go over the github workflow I created that allows me to test bash scripts using BATS against multiple versions of Bash.

TL;DR: See my github workflow : bats-multi-bash.yml

My Bash Script

The script in question is my Bash-TPL project, which is a light-weight shell-scripting template engine.

My Testing Framework

I chose BATS as the testing framework, as its comprehensive, tests are easy to write, and its Bash all the way down !

I had already written an extensive suite of tests, so I was confident they would reveal any compatibility issues once I figured out how to run them against older Bash versions.

Finding Older Bash Versions

In researching how I was going to run my tests against older bash versions, I discovered the Official Bash Docker Repository

Local Testing

This made running the tests on a specific bash version very easy to do on my local machine:

$ docker --rm -it -v"${PWD}:/bash-tpl" bash:3.2

bash-3.2# apk add bats diffutils
# ...
OK: 8 MiB in 21 packages

bash-3.2# cd /bash-tpl
bash-3.2# bats test

1..92
ok 1 BASH_TPL_TAG_DELIMS: Should do nothing when unset or empty
ok 2 BASH_TPL_TAG_DELIMS: Should error on invalid input
ok 3 BASH_TPL_TAG_DELIMS: Should process valid input
# OK looking good !
# ...
# DOH!
not ok 42 misc-function: escape_regex
not ok 43 misc-function: normalize_directive
# ...

Hate Compatibility Much?

So it turned out that my script only worked on Bash 5.1 :(

Checking Multiple Bash Versions

Once I identified all of the compatibility issues, I was able to work on fixing them, using the above technique to test against multiple Bash versions. Specifically, I ran tests against:

Bash Version 3.2 (bash:3.2)
Bash Version 4.4 (bash:4.4)
Bash Version 5.0 (bash:5.0)
Bash Version 5.1 (bash:5.1)

Auto-Detecting Future Issues

Having successfully fixed the compatibility issues, and making a new release, I set out to create a github workflow to run these tests for me in the future.

Workflow Research

Bash Docker Images

I had to determine if I could utilize the previously discovered Bash docker images within a github workflow.

Run a Single Bash Image

My first goal was to determine if I could run the workflow within just a single docker image.

Thanks to the well-documented Workflow Syntax For Github Guide, I discovered the jobs.<job_id>.container configuration.

jobs:
  my_job:
    container:
      image: "bash:3.2"

This will run your job steps inside the specified container !

Configuring BATS

Next I needed to install BATS into my fresh new Bash container.

I knew I could issue an apk add bats command, but I wanted to have more control over the actual version of BATS being used.

GitHub Actions Marketplace

I figured I probably wasn't the first person who wanted to run BATS in a workflow, so I searched the github actions marketplace.

Sure enough, there was already an action for configuring BATS:

https://github.com/marketplace/actions/setup-bats-testing-framework

Most importantly, it allows you to declare which version of BATS you want to install.

For me, that was the shiny new 1.5.0:

jobs:
  my_job:
    steps:
      - name: Setup BATS
        uses: mig4/setup-bats@v1
        with:
          bats-version: 1.5.0

Multiple Bash Versions

Now that I could successfully run my tests using a single container, it was time to figure out how to use multiple containers.

Enter The Matrix

From the github workflow documentation of the jobs.<job_id>.strategy.matrix strategy:

You can define a matrix of different job configurations. A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one supported version of a programming language, operating system, or tool. A matrix reuses the job's configuration and creates a job for each matrix you configure.

Not Exactly New

I first learned about the github workflow matrix strategy when implementing github-repo-stats to save stat history for all of my repositories.

But What About Containers?

But I couldn't find any examples of a matrix being used for container setup.

... Favors The Bold

I decided to give a try anyway - And It Worked !

jobs:
  my_job:
    strategy:
      matrix:
        bash: ["bash:3.2", "bash:4.4", "bash:5.0", "bash:5.1"]
    container: 
      image: ${{ matrix.bash }}

Putting It All Together

Now that I had all the pieces worked out, I could finally implement my workflow.

Below is the version of the workflow at the time of posting:

bats-multi-bash.yml

name: BATS Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  workflow_dispatch:

jobs:
  bats:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        bash: ["bash:3.2", "bash:4.4", "bash:5.0", "bash:5.1"]
    container: 
      image: ${{ matrix.bash }}
    steps:
      - name: Install packages
        run: apk add diffutils

      - name: Setup BATS
        uses: mig4/setup-bats@v1.2.0
        with:
          bats-version: 1.5.0

      - name: Checkout code
        uses: actions/checkout@v2

      - name: Run bash-tpl tests
        run: bats test/

      - name: Run template tests
        run: bats test/tpl

Results

The BATS tests run successfully on all specified Bash versions, and they're fast!

Conclusion

Thank you for reading - I hope you found this post helpful. Please let me know if you have any comments or questions.

-TekWizely

My-Alternatives: A wrapper for update-alternatives offering user-level customizations. Supports Debian, SUSE, and RedHat

TekWizely — Wed, 10 Nov 2021 21:40:00 +0000

I'm excited to announce release v0.7.0 of my-alternatives

https://github.com/TekWizely/my-alternatives

My-Alternatives is a light-weight wrapper over update-alternatives, offering user-level customizations.

Supports Debian, SUSE, and RedHat

Easy to Get Started

With my-alternatives, configuring custom alternatives is as easy as:

# initialize my-alternatives
# note: place this in your .profile
$ eval "$( my-alternatives init )"

# customize an alternative
$ my-alternatives select <name>

See the Project's Homepage for more information

Release Notes - v0.7.0

Re-Write

This release marks a full re-write of the my-alternatives tool, changing it into wrapper for update-alternatives that manages user-level configurations and uses them when invoking update-alternatives (i.e --admindir & --altdir).

This new approach makes it much easier to support all available commands for managing your custom alternatives.

RedHat

This release also includes support for RedHat.

This is significant because RedHat maintains its own implementation of update-alternatives, which is slightly different than the Debian version.

The RedHat version does not include the uber-useful --query command, making it impossible to integrate it using just the public API.

As such, supporting it requires a hack, exploiting knowledge of the tool's private internals.

SUSE

The SUSE implementation of update-alternatives is really just a re-branded version of the Debian tool.

Multiple Scripts

As part of introducing RedHat support, this release now includes two versions of the my-alternatives script, each named according to the primary OS flavor they support:

Debian / SUSE : my-alternatives-debian
RedHat / CentOS : my-alternatives-redhat

ShowDEV: My-Alternatives - Hacking update-alternatives to make user-level changes

TekWizely — Wed, 29 Sep 2021 18:39:34 +0000

Introducing My-Alternatives

https://github.com/TekWizely/my-alternatives

My-Alternatives takes an honest run at making a useful tool to allow you to configure alternatives (see: update-alternatives) that only affect your local account / shell sessions.

No root/sudo

My-Alternatives does not require root / sudo privileges to use, as it creates and maintains user-owned alt root directories that store your alternative links.

Quick Example

Here's a quick example of using my-alterantives to configure a local override for the pager alternative:

confirm current system value for pager

$ which pager

/usr/bin/pager

take a closer look

$ ls -l /usr/bin/pager

lrwxrwxrwx root root  /usr/bin/pager -> /etc/alternatives/pager

$ ls -l /etc/alternatives/pager

lrwxrwxrwx  root  root  /etc/alternatives/pager -> /usr/bin/less

init my-alternatives

$ eval "$( my-alternatives init )"

configure pager

$ my-alternatives config pager

There are 2 choices for the alternative pager (providing ${MY_ALTS_ROOT}/bin/pager).

  Selection    Path            Priority   Status
------------------------------------------------------------
  1            /bin/more        50        
  2            /usr/bin/less    77        system value

Type selection number:

select non-system value '/bin/more'

... Type selection number: 1

configured local alternative for pager: /bin/more

confirm updated value

$ which pager

/tmp/my-alts.abcd/bin/pager

take a closer look

$ ls -l "${MY_ALTS_ROOT}"/bin/pager "${MY_ALTS_ROOT}"/man/man1/pager.1.gz

lrwxrwxrwx  user  group  bin/pager -> /bin/more
lrwxrwxrwx  user  group  man/man1/pager.1.gz -> /usr/share/man/man1/more.1.gz

Per-Shell Alternatives

The example above shows how to create per-shell alternatives.

That is, using my-alternatives init without specifying a target directory results in the creation and use of a temporary directory that only the current shell session knows about.

User-Level Alternatives

You can configure user-level alternatives by providing a specific init directory i.e:

$ eval "$( my-alternatives init ~/.my-alts )"

More Information

Please see the Project Homepage for more inrmation.

Thanks for looking and please let me know if you have any questions!

-TekWizely

ShowDEV: Bash-TPL - A smart, lightweight shell script templating engine

TekWizely — Sat, 18 Sep 2021 16:46:24 +0000

I know the landscape is crowded, but I'd like to offer my submission for an Easy To Use / Easy To Maintain template engine:

Introducing Bash-TPL : A Smart, lightweight shell script templating engine, written in Bash

https://github.com/TekWizely/bash-tpl

FEATURES

Lightweight

Single bash script
Easy to ship with your project or build process

Smart Indentation Tracking

Removes unwanted whitespace from rendered text files
Encourages well-formatted mix of template tags and textual content

Generates Reusable Shell Scripts

Can manage & invoke shell scripts without bash-tpl
Only need bash-tpl when your source templates change

Shell Agnostic

Uses standard printf, variable, and sub-shell constructs
Templates can target any modern shell

Supports Includes

Can organize your templates as smaller, reusable components
Indentation tracking even works across includes !

Flexible Delimiter Support

Can customize all template delimiters
Can modify delimiters mid-template
Can include templates with differing delimiters

Quick Example

As is the way: A quintessential hello world example is of course in order:

hello.tpl

Hello, <% ${NAME:-World} %>

compile + run

$ source <( bash-tpl hello.tpl )

Hello, World

compile + run with NAME

$ NAME=TekWizely source <( bash-tpl hello.tpl )

Hello, TekWizely

view compiled template

$ bash-tpl hello.tpl

printf "%s\n" Hello\,\ "${NAME:-World}"

More Information

This hello example is really just the start of what bash-tpl can do.

There's a full README on the Project Home Page.

If you're looking for an easy solution for creating maintainable templates to generate well-formatted text files, I hope you'll give my project a try.

I'm happy to answer any questions or work through any use-cases you might have for templates and see how bash-tpl might help.

Feel free to comment and thanks for looking!

-TW

Bingo - Its Homebrew for "go install"

TekWizely — Mon, 23 Aug 2021 18:20:15 +0000

Do you love the simplicity of being able to download & compile golang applications with 'go install', but wish it were easier to manage the compiled binaries?

Introducing Bingo:

GitHub : https://github.com/TekWizely/bingo

Bingo makes installing and managing go install-based packages a lot easier.

Features

Keeps a link between the installed binary and the source package
Can update / uninstall binaries using the name of the binary (i.e bingo update goimports)
Can install binaries to a location of your choice
Can control the name of the installed binary
Can install multiple versions of the same package (using different names for the binaries)

pre-commit-golang - v1.0.0-beta.4 - Go Mod Tidy, GoFumpt, StaticCheck

TekWizely — Sun, 15 Aug 2021 03:23:39 +0000

Its been a busy week since the v1.0.0-beta.1 announcement.

Here's a quick recap of recent additions:

v1.0.0-beta.4
- Support for staticcheck
v1.0.0-beta.2
- Support for go mod tidy
- Support for gofumpt
v1.0.0-beta.1
- Support for invoking custom tools

As an example of invoking custom tools, here's a snippit I gave to a user recently who wanted to invoke golines:

# ...
      hooks:
            # Run 'golines -l --dry-run $FILE' for each staged .go file
        -   id: my-cmd
            name: go-lines
            alias: go-lines
            args: [ golines, -l, --dry-run ]

            # Run 'golines -l --dry-run .' in the repo root folder
        -   id: my-cmd-repo
            name: go-lines-repo
            alias: go-lines-preo
            args: [ golines, -l, --dry-run, . ]

You can read about all pre-commit-golang features on project's homepage:

https://github.com/TekWizely/pre-commit-golang

Pre-commit-Golang v1.0.0-beta.1 – Now with support for running custom go tools

TekWizely — Sat, 07 Aug 2021 01:09:52 +0000

About

pre-commit-golang is a set of pre-commit hooks for Golang with support for monorepos, the ability to pass arguments to all hooks, and the ability to invoke custom go tools.

Quick Links: Project Page | Available Hooks | Installation | Releases

Release Announcement: v1.0.0-beta.1

I'm excited to announce that v1.0.0 is finally on the horizon !

This release accomplishes the two biggest things I wanted to reach v1.0.0:

Invoking Custom Tools
Removing Duplicate Code

Read below to learn more about both of these.

See the project's readme for more in-depth documentation.

NOTE: Due do the extent of new code in this release, I'm first releasing it as a beta until it has some time in the wild.

I've done a lot of local testing, but I don't have an automated test suite for the project yet, so please take a minute to report issues if you find any.

Invoking Custom Tools

While this project includes builtin hooks for many popular go tools, it's not possible to include builtin hooks for every tool that users might want to use.

To help accommodate those users, this release introduces the ability to invoke custom go tools.

Using the my-cmd-* hooks, you can invoke custom go tools in various contexts.

Hook ID	Description
`my-cmd`	Run `'$ARGS[0] [$ARGS[1:]] $FILE'` for each staged .go file
`my-cmd-mod`	Run `'cd $(mod_root $FILE); $ARGS[0] [$ARGS[1:]] ./...'` for each staged .go file
`my-cmd-pkg`	Run `'$ARGS[0] [$ARGS[1:]] ./$(dirname $FILE)'` for each staged .go file
`my-cmd-repo`	Run `'$ARGS[0] [$ARGS[1:]]'` in the repo root folder
`my-cmd-repo-mod`	Run `'cd $(mod_root); $ARGS[0] [$ARGS[1:]] /...'` for each module in the repo
`my-cmd-repo-pkg`	Run `'$ARGS[0] [$ARGS[1:]] ./...'` in repo root folder

Configuring the hooks

The my-cmd hooks are configured entirely through the pre-commit args attribute, including specifying which tool to run (ie $ARGS[0] above)

Examples

Here's an example of what it would look like to use the my-cmd hooks to invoke go test if it wasn't already included:

.pre-commit-config.yaml

# ...
      hooks:
            # Run 'cd $(mod_root $FILE); go test ./...' for each staged .go file
        -   id: my-cmd-mod
            name: go-test-mod
            alias: go-test-mod
            args: [ go, test ]

Removing Duplicate Code

This release constitutes a huge re-factoring of the code, moving common logic into the lib/ folder, and removing as much code duplication as possible.

For example, here is the complete content of go-lint.sh :

#!/usr/bin/env bash
# shellcheck disable=SC2034  # vars used by sourced script
error_on_output=0
cmd=(golint -set_exit_status)
# shellcheck source=lib/cmd-files.bash
. "$(dirname "${0}")/lib/cmd-files.bash"

Thats it !

This should make it much easier to add new hooks, as well as all hooks being able to take advantage of future bug fixes and enhancements to the common code.

pre-commit-golang v0.8.3 - Now with revive support

TekWizely — Sun, 30 May 2021 04:10:47 +0000

About

pre-commit-golang is a set of pre-commit hooks for Golang with support for Modules.

Quick Links: Project Page | Available Hooks | Installation | Releases

Release Announcement: v0.8.3

This release adds support for revive, a ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint.

revive hooks

The following revive hooks are now available:

Hook ID	Description
`go-revive`	Run `'revive [$ARGS] $FILE'` for each staged .go file
`go-revive-mod`	Run `'cd $(mod_root $FILE); revive [$ARGS] ./...'` for each staged .go file
`go-revive-repo-mod`	Run `'cd $(mod_root); revive [$ARGS] ./...'` for each module in the repo

Installing revive

go get -u github.com/mgechev/revive

Learning More About revive

https://github.com/mgechev/revive#usage
revive -h

Conclusion

If you use git for your golang project's source control, I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you for your time,

-TekWizely ( https://github.com/TekWizely )

pre-commit-golang v0.8.2 - Now with gosec support

TekWizely — Sun, 14 Mar 2021 02:01:16 +0000

About

pre-commit-golang is a set of pre-commit hooks for Golang with support for Modules.

Quick Links: Project Page | Available Hooks | Installation | Releases

Release Announcement: v0.8.2

This release adds support for gosec, a popular golang security checker.

go-sec hooks

The following gosec hooks are now available:

Hook ID	Description
`go-sec-mod`	Run `'cd $(mod_root $FILE); gosec [$ARGS] ./...'` for each staged .go file
`go-sec-pkg`	Run `'gosec [$ARGS] ./$(dirname $FILE)'` for each staged .go file
`go-sec-repo-mod`	Run `'cd $(mod_root); gosec [$ARGS] ./...'` for each module in the repo
`go-sec-repo-pkg`	Run `'gosec [$ARGS] ./...'` in repo root folder

Installing gosec

go get github.com/securego/gosec/v2/cmd/gosec

Learning More About gosec

https://github.com/securego/gosec#usage
gosec (no args)

Conclusion

If you use git for your golang project's source control, I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you for your time,

-TekWizely ( https://github.com/TekWizely )

Run v0.7.2 - Easily manage and invoke small scripts and wrappers

TekWizely — Wed, 18 Mar 2020 20:34:28 +0000

About

Do you find yourself using tools like make to manage non build-related scripts?

Build tools are great, but they are not optimized for general script management.

Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.

Quick Links: Project Page | Examples | Installing | Releases

Project Update - v0.7.2

You can read about the new features and bug fixes below.

If you've been following run, I hope you'll find these updates useful.

If this your first time reading about run, and if you're at all interested in managing task runners and scripts, I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you,

-TekWizely

New Features

Assertions

Assertions let you check against expected conditions, exiting with an error message when checks fail.

Assertions have the following syntax:

ASSERT <condition> [ "<error message>" | '<error message>' ]

Note: The error message is optional and will default to "Assertion failed" if not provided

Condition

The following condition patterns are supported:

[ ... ]
[[ ... ]]
( ... )
(( ... ))

Assertion Example

Runfile

##
# Not subject to any assertions
world:
    echo Hello, World

# Assertion applies to ALL following commands
ASSERT [ -n "${HELLO}" ] "Variable HELLO not defined"

##
# Subject to HELLO assertion, even though it doesn't use it
newman:
    echo Hello, Newman

##
# Subject to HELLO assertion, and adds another
# ASSERT [ -n "${NAME}" ] 'Variable NAME not defined'
name:
    echo ${HELLO}, ${NAME}

example with no vars

$ run world

Hello, World

$ run newman

run: Variable HELLO not defined

$ run name

run: Variable HELLO not defined

example with HELLO

$ HELLO=Hello run newman

Hello, Newman

$ HELLO=Hello run name

run: Variable NAME not defined

example with HELLO and NAME

$ HELLO=Hello NAME=Everybody run name

Hello, Everybody

Note: Assertions only apply to commands and are only checked when a command is invoked. Any globally-defined assertions will apply to ALL commands defined after the assertion.

Ignoring Script Lines

You can use a # on the first column of a command script to ignore a line:

Runfile

hello:
    # This comment WILL be present in the executed command script
    echo "Hello, Newman"
# This comment block WILL NOT be present in the executed command script
#   echo "Hello, World"
    echo "Goodbye, now"

Note: Run detects and skips these comment lines when parsing the runfile, so the # will work regardless of what language the script text is written in (i.e even if the target language doesn't support # for comments).

Bingo v0.2.0 - Its Homebrew for "Go Get" - Now With Update and Version Support!

TekWizely — Thu, 12 Mar 2020 15:56:40 +0000

Introduction

Do you love the simplicity of being able to download & compile golang applications with 'go get', but wish it were easier to manage the compiled binaries?

Introducing Bingo:

GitHub : https://github.com/TekWizely/bingo

Bingo makes installing and managing golang-compiled binaries a bit easier.

Features

Keeps a link between the installed binary and the source package
Can install binaries to a location of your choice
Can control the name of the installed binary
Can install multiple versions of the same package (using different names for the binary)
Each binary's source package is isolated and managed in its own separate $GOROOT

Release Announcement: v0.2.0

Highlights

Update Support
You can now update existing binaries

Version Support
You can now specify which version of a package to install or update

Examples

Below are some quick usage examples. See the project's homepage for more detailed documentation and installation instructions.

# Install package latest version as "hello"
$ bingo install github.com/golang/example/hello

# Install specific version
$ bingo install github.com/golang/example/hello@v1.2.3

# Install package with a different binary name
$ bingo install -n foo github.com/golang/example/hello

# Update a binary to latest version
$ bingo update hello

# Update a binary to specific version
$ bingo update hello@v1.2.3

# List installed binaries
$ bingo installed

# Display a binary's associated package
$ bingo package hello

# Uninstall a binary and associated package folder
$ bingo uninstall foo

Conclusion

If you're looking for better ways to manage binaries installed via 'go get', I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you for your time,

-TekWizely ( https://github.com/TekWizely )

Show DEV: Bingo - The missing package manager for golang binaries

TekWizely — Mon, 17 Feb 2020 20:11:48 +0000

Introduction

Do you love the simplicity of being able to download & compile golang applications with 'go get', but wish it were easier to manage the compiled binaries?

Introducing Bingo:

GitHub : https://github.com/TekWizely/bingo

Bingo makes installing and managing golang-compiled binaries a bit easier.

Features

Keeps a link between the installed binary and the source package
Can install binaries to a location of your choice
Can control the name of the installed binary
Can install multiple versions of the same package (using different names for the binary)
Each binary's source package is isolated and managed in its own separate $GOROOT

Examples

Compiling + Installing Binaries

To install a binary with bingo, use the golang application's full package path, same as you would with 'go get'.

hello example

$ bingo install github.com/golang/example/hello

Installing binary hello from package github.com/golang/example/hello
Downloading package (folder: '~/.bingo/pkg/hello')
Compiling package
Installing binary (file: '~/.bingo/bin/hello')
Done

$ ~/.bingo/bin/hello

Hello, Go examples!

Binary Naming

By default, the installed binary will be named after the last folder element in its package path.

As you saw above, installing the github.com/golang/example/hello package installed a binary named hello.

You can override this behavior and specify the binary name at the time of installation:

install hello example as 'foo'

$ bingo install -n foo -q github.com/golang/example/hello

$ ~/.bingo/bin/foo

Hello, Go examples!

Listing Installed Binaries

To see a list of installed binaries, use the installed command:

$ bingo installed -p

Bingo-managed binaries (folder: '~/.bingo/bin')

 - foo github.com/golang/example/hello
 - hello github.com/golang/example/hello

Displaying A Binary's Associated Package

If you need a reminder of which package a binary was compiled/installed from, you can use the package command:

$ bingo package hello

github.com/golang/example/hello

Uninstalling Binaries / Packages

Use the uninstall command to uninstall binaries:

$ bingo uninstall foo

Uninstalling binary foo from package github.com/golang/example/hello
Removing binary (file: '~/.bingo/bin/foo')
Removing package (folder: '~/.bingo/pkg/foo')
Done

$ bingo installed -q

hello

NOTE: Uninstalling a binary also removes the associated package folder.

Requirements

Run

Bingo exists as a Runfile, and requires the Run tool to operate:

https://github.com/TekWizely/run

Bash

Bingo (currently) uses bash for its command scripts.

Readlink

Bingo uses symbolic links to associate binaries to their packages.

The scripts use readlink to resolve symbolic links.

Installing Bingo

Releases

See the Releases page for downloadable archives of versioned releases.

Brew Tap

While brew core support is in the works, I have also created a tap to ensure the latest version is always available:

https://github.com/TekWizely/homebrew-tap

install bingo directly from tap

$ brew install tekwizely/tap/bingo

install tap to track updates

$ brew tap tekwizely/tap

$ brew install bingo

Configuration

See the Work Folders section on the project's main page for details on configuring the various folders needed by bingo, including which folder to install binaries in.

License

The tekwizely/bingo project is released under the MIT License.

Conclusion - A Toy Trying To Take Itself Seriously

Although designed as a set of toy scripts to play around with the idea, bingo is trying to take itself seriously and make a real run at being a useful tool.

If you're looking for better ways to manage binaries installed via 'go get', I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you for your time,

-TekWizely ( https://github.com/TekWizely )