WHIZARD: Bootstrap the environment

We have an ongoing discussion in the WHIZARD group about the (missing) user-friendliness of the installation process. Roughly speaking, the installation process involves beside the correct incantation of the Autotools work chain also the correct installation of any required external tools. WHIZARD is written mainly in Fortan, so you need a Fortran compiler, and an OCaml compiler for the matrix-element generator O'Mega.¹ That is the first problem that a user can solve pretty easily with their system packet manager. Next, setting the configure options right is a another blazing hell of choosing the exact right options in the exact right way. Do not expect any help on this! Now, when WHIZARD should be linked with any external tool that tool has to be build correctly, too. I'm looking suspiciously at any invocation of --std=cXX.

The basic idea would be for us to provide a bootstrap script, which does all the heavy lifting: downloading the external tools, configure and build them, and spinning up the WHIZARD build process - all in one place. In the end, the use only needs to source a single script that does all the path mangling. At some point, there was even a script, called Instant Whizard. However, that script had an entirely different background: It should provide the compiler, i.e. it downloaded Autotools, GCC and OCaml and build it, everything else was just an add-on. With that background in mind, it is not surprising that Instant Whizard was not really user-friendly with regard to optional settings, and we never really cared about it.

During my PhD, I refactored Instant Whizard to such an extend that I could use it for bootstrapping my WHIZARD installations, i.e. installing all external tools, which WHIZARD can incorporate, in a correct way in a single place and drop the appropriate configure options, which I could then refine if I wished so.

And, in a naive approach, I thought I would drop that script in the WHIZARD group and have it shipped along with WHIZARD. Everyone would be happy… .

An heated discussion arose and it did not end well for me and for the script. I think because the script did not fulfill any kind of expectation for anyone (except mine). Let me give you some of the threads of the discussions:

• Which scripting language should we use? Python, Bash? It seems that Python is the class enemy.
• Commandline-driven? Single invocation and run through? A menu-based user-interface? Auto-completion?
• Default usage? Which are the default tools to be installed? In which versions?
• Maintenance? Who will keep the versions of the tools up-to-date and test everything?
• …

That is a hell of different answers/opinions, and there are much more details which I have skipped. And my answer to all of them was quite simple: The simple user just needs to run a script, which show him what it will do, and then await a confirmation or rerun the script with an "enforce" flag. On top, the experienced user may want to change some settings by adding arguments to the script call or place environment variables. You can do this with a fancy menu, but someone has to write and maintain it and I am lazy.²

In my humble opinion, there is just no need for a user-interface, auto-completion and what-so-ever. If we give the user a script, he should just run it, understand which tools it will install and then finally let it do its deed. Side note: In principle, the user should always inspect the script first, whether it may contain malicious code - in the best of all worlds. However, we know that this an utopian idea, not every user is proficient with Bash and/or has the will and time to inspect an Bash script of more than 25 lines.

The discussion around which tool version is best to ship and testing all (combinations) of them, is a bit harder to answer: First, I would use the newest version working. WHIZARD does quite a bit of heavy-lifting with regard to continuous integration (not much compared to industry standards, but still more than most other academic software has run through). Therefore, we can assume that our picked versions seem to work. Second, we already do continuous integration, it's simple to add another scheduled job, which runs once a week and tests the script on the current release.

Last, but not least, the question of maintenance: I can answer that quite simple: For each release, we just adapt the versions numbers and let it test. We only need to incorporate into our deployment (still done manually, because .. reasons?).

What is the conclusion of all this? I do not know. But, as long, as everyone has a more or less strong opinion on a specific way how such a script should work, I do not see how such a script will come together.