1. This adds additional dependency - bash and all dependencies used by i.jpillora.com, which was not required to use this script before.

2. I have a fear using external services without informing user about this. curl | bash is very bad pattern to include into script. But it can be described in a README.md

How about parsing architecture and platform using uname and preform url from this:

https://github.com/siderolabs/talos/releases/latest/download/talosctl-<platform>-<arch>

Or if version specified:

https://github.com/siderolabs/talos/releases/download/<version>/talosctl-<platform>-<arch>

See approach from this file:

https://github.com/deckhouse/deckhouse/blob/ab6faa3ad220f203117626a15052333bf84154dc/Makefile#L11-L46

Those are great points.

• I agree the curl | bash is a less-than-ideal pattern, as well as an additional dependency along with all the binaries that the generated install script from J.Pillora's installer checks for [although I believe all the checks are for binaries expected on a POSIX-compliant system]. The design was a "quick-fix" I chose w/o considering the extra deps it added

I'll see what I can do to address your concerns by specializing the check_or_install function to our specific use case for talosctl

FWIW, I initially chose to design in this way anticipation of another feature contribution which will allow the user to select the to-be-installed talosctl version from a list as it would need to ensure yq was available for easily parsing Github API results, BUT I can still accomplish that and narrow dependencies to just the actual binaries that we need: talosctl and yq.

Ill hammer away and get back with you :)

Thank you @TrooperT ❤️

I mean, that I don't against using curl | bash but it should be described in README.md insead of placing it into script.
So user will invoke it at their own risk, or they still have the opportunity to install it from their distribution.

From the other side script can check if required binary exists and can be running.