Why binaries over imports?

[robinbraemer]

What is the rationale behind running binaries like helm3 as an os command over importing helm as a library to more closely and reliably do operations and get outputs?

Just curious ;)

My thought process would be since helm is written in Go it can be utilized as a library in the helm3 mixin.
The upside to this is fine control and type safety, as well as strictest compatibility to use features in versions and no additional binary to install into the CNAB invocation image.

The downside to this you have to learn the API of the helm codebase which might take longer than just running it as os Cmd in go for faster dev speed, for the sacrifice of possible instabilities due not having full control in code.

Since a CNAB is isolated and abstracted away by the bundle maintainer to make it work it doesn't matter to the outside bundle user, I know that. But what were your thoughts here?

@MChorfa

[schristoff]

Hey!
This is a great question and one I asked very early on when I joined Porter.
The reason was that by consuming binaries we make it that the broader community can make mixins and hopefully lower the bar to entry/maintainability.
However, looking at the mixin skeleton, you should still be able to do imports as well! (This is something I should show soon)