change from POSIX sh/Bash to Python

[reidpr]

It's been proposed multiple times to rewrite our shell scripts in Python. This issue is to capture that discussion.

Pros:

• Python is way easier to program in.

Cons:

• Python is less portable.
• Everyone would still be required to use 3 space indentation.

See also issue #396, which proposed changing from POSIX sh to Bash.

[reidpr]

@trandles-lanl stated offline:

From a pure portability point of view I’d prefer you stick with shell. That said, python today is where perl was a decade ago, it’s nearly impossible to install any linux distro without also installing python. I do worry about version portability and an explosion of required modules. The closer you can adhere to code that’s compatible with both version 2 and 3 (for the next year or so, 2 is slowly going away) the better. If it’s possible to stick to just python’s core library you’re likely to maximize portability. The moment you stray into “pip install” hell and/or a README that includes “activate your virtual environment” is the moment when I’m afraid you start to lose a lot of the ease-of-install and ease-of-use arguments.

[j-ogas]

Opinions (in no particular order) followed by a response to the initial cons.

• Charliecloud has too many scripts (even with ch-convert proposed in new script ch-convert #698) which results in a a steep learning curve and a disjoint-feeling workflow. This may actually benefit developers, but discourage users.
• Charliecloud may benefit from having a familiar UI, e.g., primary commands with sub commands, similar to docker (see example code block below).
• We are a small team, the amount of time we spend on scripting matters, therefore ease of programming and mileage (power) of scripting tools shouldn't be scoffed at.
• Python may allow us to infer input better which will in turn abstract more of the workflow away and make the experience more user friendly.

Example simplified code block:

$ ch RUN|BUILD|MOVE [OPTIONS]
$ ch build [...]
$ ch move [...]
$ ch run [...]

Response to cons:

Cons:

* Python is less portable.

Technically true, however, I do wonder about the validity of a python portability concern in our intended setting, e.g., scientific computing and HPC. Spack is huge in this area and python portibility doesn't seem to be hindering them at all. Thus, I'm a little skeptical about python portability issues.

* Everyone would still be required to use 3 space indentation.

Not a con for those without stake in the indentation dispute.

[reidpr]

I think the number of scripts and possible sub-command structure are orthogonal to the language of implementation.

[shanegoff]

I think the number of scripts and possible sub-command structure are orthogonal to the language of implementation.

This is something I have gotten hung up on. 23 binaries means 23 sub commands. Either direction we go, we will still have a need for making commands smarter to have less of them.

• Everyone would still be required to use 3 space indentation.

We already grudgingly adhere to this anyway.

Python is less portable.

I think this has become less meaningful in 2020. Python is installed on almost every distro out there. Certainly every distro we may target. Any place we are going to be building images and such will almost certainly have a version of python installed.

I do think we need to be wary of the dependency nightmare we could get in to depending on a lot of packages. But on the other side of that coin, Anaconda is very popular in computing which bundles a huge number of packages already (264 packages). I think it is sensible to take advantage of those packages for OPTIONAL functionality if needed.

I think python is very well suited to serve in a front end wrapper capacity for charliecloud. I am also biased, as I am much less experienced with bash.

We also already depend on several python based tools.

[reidpr]

making commands smarter to have less of them

We could also dump some of them into libexec, i.e., make them no longer user-facing.

[rstyd]

I think another argument for Python is that the Python code could be more maintainable and leaner. Some of the magic that has been proposed in the Goff plan would be a pain to implement in POSIX shell. We could definitely do it however.

[trandles-lanl]

I think it would be wise to distinguish between a build environment and a runtime environment. The concerns about python portability in a build environment are a lot less than in a runtime environment. I wouldn't take for granted that a user will have all of the same software on a cluster compute node that they have on a cluster login node. The trend we're seeing on future platforms is to containerize everything and provision compute nodes as lightly as possible.

[reidpr]

Based on all that, I'm inclined to stick with a rule of: anything used in a runtime environment should be POSIX sh if at all possible and Bash if not, while things used solely in a build environment can be Python, with minimal dependencies beyond the standard library.