[bin][pub] Rethink structure of extractmodulepart and createdockerimage
extractmodulepart.sh an install script is generated that pulls the dependencies. These are pulled within the directory of execution -> thus, the workflow at the end is that you pull the pub-module and then execute the install script from one level above it. Afterwards, you would run
I think many people create their own (pub-)module directly when they start working on code that could lead to a publication and develop the code therein. In that case the
extractmodulepart.sh step could be obsolete, and we could think about separating the install script generation from module extraction.
Also, it might be more convenient to write the install script such that one calls it directly from the folder of the pulled pub-module. Or alternatively, the install script could be such that it clones all repositories and also runs dunecontrol. Then one could do:
wget MY_PUB_MODULE_INSTALL_SCRIPT chmod +x install.sh ./install.sh
createdockerimage script assumes the type of install script that comes from
extractmodulepart.sh, as it puts the following logic in the
- Copy module in image
- Copy install script in image top dumux folder
- Run install script
- Run dunecontrol
So, this would (probably) be incompatible with types of install scripts other than the ones resulting from
Maybe we could think about factorizing/restructuring things. It would be good if
createdockerimage had less requirements on the structure of the module, its install script and the place from where it must be executed.