Improve application installation scripts under folder user-install

[frgomes]

Related: #23 #35

Background

Application installation scripts under folder user-install aim to install applications without need of root access, at least in theory if everything goes according to plan.

Every application has it's own behaviour and requirements, meaning that there's no uniform way to tell what the end user has to do in order run a certain application of interest. Certain applications require the definition of environment variables, certain applications are provided as container images and so on.

In order to tackle this problem, when an application is installed we provide a shell script which initializes whatever needs to be initialized in order to make it work out when required. In particular, a very common thing involves updating the PATH environment variable so that the installation folder is included.

Terminology

With so many scripts all over the place eventually changing PATH, it becomes necessary to make it clear what we are talking about:

• postactivate is a shell script created by mkvirtualenv in a virtual environment of your choice. This script is initially empty. You can add logic to it according to your requirements.

• Installation scripts are shell scripts under folder user-scripts of this project. These scripts may download applications, install them under a certain folder and may create "application activation scripts" under a standard location.

• Application activation scripts should not be confused with postactivate scripts. Application activation scripts are created by installation scripts, managed by us. These application application scripts should not be touched by the user in general. These scripts must be executed in order to configure the user session so that the application can be launched when the user requests it.

What this ticket is about

One issue we had before was that it was necessary to add some logic manually to postactivate scripts (i.e.: in virtual environments) in order to guarantee that all application activation scripts are executed when the user switched from one virtual environment to another.

The installation scripts should be clever enough to do everything automatically. So, if application activation scripts need to be executed... and this seem to be inescapable... the installation scripts should add some logic to the postactivate script of the current virtual environment, if any.

Also, application activation scripts should also be executed in case the user is not using virtual environments at all.

But the most important aim of this ticket is providing the ability to install/activate multiple versions of applications. In a nutshell: you may be interested to have:

• Python2, Java8, Scala11 in virtual environment p2j8s11;
• Python3, Java12, Scala13 in virtual environment p3j12s13.

This will be possible easily, since each virtual environment has its own postactivate script and it's private set of application activation scripts.

Despite all the flexibility depicted above, nothing prevents you of simply ignoring virtual environments entirely, in case you don't need them and you simply don't care. In this case, the current implementation provided by #35 already provides a fall back behaviour which does just that.

Tasks

• Make sure that installation scripts save application activation scripts under current virtual environment, if any. Otherwise, fall back to ~/.bashrc-scripts/installed.
• Make sure that installation scripts have ability to instrument the postactivate script under the current virtual environment, if any. This way, activating a virtual environment triggers the execution of all application activation scripts. Nothing needs to be done in case there's no current virtual environment.
• Make sure that configuration at startup run application activation scripts from hinted virtual environment, if any. Otherwise, fall back to ~/.bashrc-scripts/installed.

Add comprehensive documentation about:

• environment variables and their use.
• virtual environments and application installation.
• initial setup process and how to pass a hint of a virtual environment.

[frgomes]

Being implemented as part of #57 branch:
https://github.com/frgomes/bash-scripts/tree/feature/0057-overhaul_turn_functions_onto_shell_scripts