arkade easily addable?

[deknos]

Hi, it's me again :) i asked the arkade project (which concentrates on kubernetes binaries) if they coulde change their deployment: https://github.com/alexellis/arkade/issues/298 and they mentioned that they and others have a similar (usual) naming process. Now my question is, is adding arkade easy and if yes, is there already a binary managed with binenv in distributions.yaml which has the same publication strategy as arkade? if not, how hard would it be to write a strategy for that?

[leucos]

I agree with @alexellis when he says:

perhaps binenv could benefit from a more flexible approach?

We need to change how we handle those download URLs. We'be been facing issues many times (latest today is k6, which is distributed as zip on MacOS, and tgz on linux).

Having a more flexible system is a must. It would solve this issue and probably #9

[alexellis]

Given that you don’t strictly need to have multiple versions of k3sup, kubectl and so forth, you could do yourselves a favour here and use arkade instead of copying its functionality.

Fork/exec the binary and let us maintain the complex rules upstream.

Have a serious think about whether you want to duplicate all that effort. It would let you focus on what you do best - installing versions of Node, Ruby and so forth. You can also contribute downloadable apps to arkade for anything you feel is missing.

arkade itself fork/execs kubectl/helm for installing apps to K8s, for downloading CLIs you can see the code in the tools.go file.

[leucos]

Thanks for the comment Alex. Well, binenv started as a need of having multiple binary version in // for the same tools, e.g. terraform / terragrunt, and being able to switch to proper version depending on project (if a .binenv.lock is in the current dir or parents, proper binary versions will be used), and "ensuring" that all developers use the same versions (so scripts break less often).

And then it grew from there.

This is just what is does: installing binaries. No heavy lifting (like installing node or ruby, where some heavier machinery is needed), no deploying manifests on kube or other fancy stuff. Just installing binaries. Some kind of goenv/rubyenv/... but for binaries. So we're far from copying arkade functionality. This not within reach, and foremost, not a goal.

Thus I do not think the effort is duplicated, and it is a fun project to do anyway. And thanks to this issue, I got to know arkade which I wasn't aware of.

[deknos]

i would agree with leucos there, multiple binaries versions are sometimes needed and i would think it's better to have more tools with different approaches, since this is more robust in the long run than unifying everything. if binenv would stop "just installing binaries" it would loose much of its value for me, though arkade itself has another value at my company. but still, there's a possibility to look in your download/install strategy for k3sup and adapt the parts we can use. :)