...

User presses Y. Script performs upgrade of all tools installed for the user and starts most recent version of autoGui and most recent version of Kepler. Previous version of user's installation are preserved and it will be possible to go back to this version later.

Preliminary investigation

All the above solutions are keeping the current approach which requires user to have a sort of local install of Kepler (composed of links or of the full sources).

Before going in that direction, we want to check the technical feasibility of running a workflow with a Kepler that remains entirely in public place. 

Kepler 

We need to check that running Kepler in such mode is possible, it involves a few actions, mainly on Michal, but with help of others when/where needed:

1. running naked kepler interactively from public install (can kepler log be stored elsewhere)
2. running kepler interactively with FC2K actors in it (simple ones, then ETS-like ones, where some might right files in current directory)
3. running these actors in stda/debug/batch (checking the behavior of the copy of sources/exec from initial place in Kepler to KEPLEREXECUTION/sandbox)
4. checking sbk execution

Kplots and other scripts 

We need to check that these scripts (currently copied within Kepler sources when Kepler is being dressed-up) can be stored outside Kepler (public place, versioned, and made available through module) and referenced from the workflow: kplots module will set up a KPLOTS_HOME which points to dir containing all the scripts, we need to check that reading this variable from the workflow will work correctly (getenv). Action on Olivier to create public install of kplots with modules, and on Dmitriy to update ETS workflow to link to Kplots scripts using the env variable set by module. These actions do no depend on Kepler actions above.