Language selection

[goldmann]

Language selection

[praiskup]

If this is meant to be just a brainstorming thread, I don't like the idea of
python/golang/perl/whatever. Either POSIX shell should be used or BASH (as
those are widely available in most of the images around).

If that is not suitable, having pre-compiled C program would be also OK.

[praiskup]

In case of pre-compiled binary ("almost" without dependencies), it does not matter
what language will be chosen. The point is to not add unnecessary run-time
requirements.

[goldmann]

Yes, issues marked with discussion label are meant to be brainstorming threads.

We want to go as far away as we can from Bash/shell. In fact this is exactly the reason to create this tool. We already maintain a lot of custom shell scripts to apply modifications to our containers. This becomes a nightmare to maintain. Another thing is that it's very complicated to do some things (XML modifications) in a stable way.

C is pretty low-level. We can get same thing with golang. As a bonus we get static linking for free.

[praiskup]

We want to go as far away as we can from Bash/shell. In fact this is
exactly the reason to create this tool. We already maintain a lot of
custom shell scripts to apply modifications to our containers. This
becomes a nightmare to maintain.

Not really. Even shell scripting allows you to do maintainable, modular
and very portable software.

Another thing is that it's very complicated to do some things (XML
modifications) in a stable way.

Hmm. Yes, if some complicated stuff is really needed, additional
requirement makes sense.

C is pretty low-level. We can get same thing with golang.

Agreed.

As a bonus we get static linking for free.

This is not benefit. The static linking is maintenance nightmare and I
personally don't like golang for that. But yeah that is just IMHO.

[praiskup]

Hmm. Yes, if some complicated stuff is really needed, additional
requirement makes sense.

By that ^^ I mean that we could avoid additional "default" requirements pretty
easily and I see no benefits in "avoiding shell scripting" target. Except the
performance - but performance POV is also kind of optional, or?

[rwngwn]

@praiskup
the main benefit of not using shell script is that tool can be easily covered by unit tests, versioned and it also will be more consistent with lesser effort. This is so hard with custom shell scripts. you know its bug difference to write a scripts which configure one application and complete configuration framework - I know all is possible in BASH but I had maintained bash scripts which implemented !!!LDAP!!! protocol and it was a nightmare so bash is great for small specific scripts but i don't like it for more general tools
And also almost no ecosystem like static analyzes, testing framework, mocking, test coverage tool doesn't exist or are not much in use in BASH ecosystem.
And to static linking - I'm not big fun of it either - BUT it is really good in a containers world, especially for stuff like this because you will get single binary which can run in almost any container and can be easily replaced and the HUGE benefit is that update of any library in container will not hit your tool - so in the layered containers is static linking for some tools really beneficial.

[rwngwn]

Also my comment to language selection. I would love to see something like golang "runner" which will spawn language independent modules and will communicate with them via some very lightweight easily implementable RPC mechanism like 9p. In that way you;ll get:

• robust and stable runner
• great set of basic modules
• easy way to implement your modules in almost any language

[vpavlin]

+1 to the previous comment.

I am not a big fan of go either:) (Seems like no one likes it, but still it's user base id getting bigger every day:) but the static linking is a great think for containers as @l-d-j said.

We should solve problems systematically which, I think, shell scripts do not support very well - first problems I was pointing out for containers were that we migrated from initscripts to systemd units, and it was a lot of work, and now we are going to start services in containers with sort of initscripts again..but less structured, more custom...not the best way to go.

[rwngwn]

CCT now support python2/3 + bash for modules. its basically decided