Incremental transition from Bash to Go (cmdline API)

[abitrolly (Anatoli Babenia)]

https://github.com/containers/toolbox is an extremely useful Bash script that spins up an unprivileged podman container to safely mess with installing libraries and changing system files without affecting the parent system.

However, the development of the tool had stalled, because the project undergoes a complete rewrite in Go - https://github.com/containers/toolbox/pull/318

As a user, I find this strategy frustrating. I’d like to continue using and patching the Bash tool while its certain parts are being rewritten and ported to Go. There are bugs that are only fixed in Go branch, and because Go branch uses bash tests for parity, the bash code there contains the fix too. But it is not released.

The idea

A standard way to enumerate and call go functions from bash.

goprog apilist                 - get list of functions in goprog
goprog apicheck <function>     - check if function exists
goprog apihelp <function>      - get function params and decription
goprog apicall <function> [param1] [param2]

Then in bash check the list of functions, and reroute existing bash functions to apicalls in goprog.

Is that possible?

[hollowaykeanho (Holloway)]

@abitrolly

A standard way to enumerate and call go functions from bash.

@abitrolly

Is that possible?

This is essentially writing your own Go program with the name goprog in a separate Github repository. Hence, it is doable on your side.

As for CLI interfaces, you can check out https://github.com/spf13/cobra and https://github.com/spf13/viper.

Enjoy your Go journey.

@abitrolly

As a user, I find this strategy frustrating. I’d like to continue using and patching the Bash tool while its certain parts are being rewritten and ported to Go. There are bugs that are only fixed in Go branch, and because Go branch uses bash tests for parity, the bash code there contains the fix too. But it is not released.

The issue is focusing the toolbox design scope and direction. You might want to communicate the issue back to that Github toolbox issue ticket.

If Go program is properly implemented, you would not be using shell script wrapper for its development and production operations, inlcuding unit testing.