<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug <span dir="ltr"><<a href="mailto:rainer_krug@icloud.com" target="_blank">rainer_krug@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span><blockquote type="cite"><div>On 19 Jul 2017, at 21:54, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:</div><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton <span dir="ltr"><<a href="mailto:Michael.Barton@asu.edu" target="_blank">Michael.Barton@asu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div><br><div>My group (CoMSES Net) is looking into Docker as a means of more reproducible research in modeling science. Initial tests have gone OK, but show that doing software with a GUI is considerably more complicated than doing code that just runs from
 the command line. It might ultimately be worthwhile to package GRASS as a Docker image. <br></div></div></blockquote></div><br></div><div class="gmail_extra">We don't have an official GRASS Docker image. Maybe it wouldn't be even that advantageous for open science purposes. </div></div></div></blockquote><div><br></div><div></div></span>I disagree here - it would be quite an advantage. See for example the suite of rocker R images which are available and also used quite a bit (I assume). There is even a spatial one (<a href="https://hub.docker.com/r/rocker/geospatial/" target="_blank">https://hub.docker.com/r/rock<wbr>er/geospatial/</a>) which was added recentlyI, and I am still planning to build on that bundle an image which includes GRASS so that you have one Docker image for all your basic spatial GIS needs.</div><div><br></div><div>Anyway - I think a  Docker image which is “officially” supported (which does not contain the GUI, only the command line) would be a very good starting point for further very useful Docker container. At least, there is another readable recipe for building GRASS from source (in addition to the TravisCI test).</div></div></blockquote><div><br></div><div>I agree. There are two or three different cases. 1) Scientific images like the R one you mentioned which won't be dedicated GRASS GIS images but rather bundles where GRASS GIS is only one of the components. 2) Testing image for build and running tests. The Dockerfile for some basic case can be directly in the GRASS repository. 3) Dedicated Dockerfile/images for specific projects, e.g. in the forestfrag3d repository there is a certain development version with a custom patch (because of a bug). In this case official image would not work because an that would be a stable release and binary.<br><br></div><div>You can look at it also from a perspective of the GRASS code source. 1) Dockerfile in the GRASS repository should use the code it lives in. 2) Some software bundle may prefer to use some binary distribution (e.g. Ubuntu PPAs). 3) Specific projects may need to use specific version of the code and will download it from the repository.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">Anyway, we have already many Dockerfiles. See for example one from me which I created for reproducibility of my recent paper:<br></div><div class="gmail_extra"><br><a href="https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile" target="_blank">https://github.com/wenzeslaus/<wbr>forestfrag3d/blob/master/Docke<wbr>rfile</a><br><br></div><div class="gmail_extra">In the case of that repository, the idea is that user can (but does not have to) run GRASS GIS or QGIS (with GRASS GIS) natively on the data created in the Docker image, but the main outputs are PNG images, so no special software is necessary.<br></div></div></div></blockquote><div><br></div></span><div>So you have a GRASS Docker image, data is stored in /data in the native system, you run the Docker GRASS to generate data, and you than can use a native GRASS to do further work with the data - is this correct?</div></div></div></blockquote><div><br></div><div>Yes. I provide people with Dockerfile through ZIP from paper or Git/GitHub (as opposed to image from DockerHub). When running the container (`docker run`) you specify what local/native directory should be linked to the /data. All the intermediate and final outputs are stored there and accessible when the `docker run` is done.<br><br></div><div>Creating and publishing a Docker image would probably add more stability to the published work as it is a frozen state with all things included. (And the repository with Dockerfile providing just the code for cases when somebody wants to modify it.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br>In past, I had success in using Docker with SSH (all local). However, for future it seems that things like Jupyter Notebook (with its widgets) or a general web interface to GRASS GIS are a way how to get a GUI while using a Docker image.<br></div></div></div></blockquote><div><br></div></span>Yes - a web GUI would be perfect - either as a standalone app which connects to a GRASS session via e.g. ssh (which could be a local GRASS Docker image) our local GRASS, or via a server which is in the  Docker image installed (as is with the RStudio images at <a href="https://hub.docker.com/r/rocker/rstudio/" target="_blank">https://hub.docker.com/r/ro<wbr>cker/rstudio/</a>. </div></div></blockquote><div><br></div><div>What is the web GUI, i.e. how to get it to the web browser seems to be the critical part here. But SSH may be a sufficient solution for now (e.g. MobaXterm seem to work well for MS Win users - although I didn't see it with Docker).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>A Jupyter Notebook (never used it, but using RStudio Notebooks - I assume very similar?) would be like literal programming - correct? And the results (e.g. results) would be embedded in the resulting document? </div></div></blockquote><div><br></div><div>Yes, they are similar. Code, text, results - all in one document. Jupyter Notebook can also do widgets, i.e. you can have sliders or input boxes, so the user doesn't have to change the code, it is enough to fiddle to a dedicated minimalistic GUI. (Connecting this with GRASS parser and modules may make it quite general and extremely interesting.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>That should not be a problem at all with a Docker image?</div></div></blockquote><div><br></div><div>Right. You run a Docker container in the background. The container runs Jupyter as server and when the right ports are open from Docker, you can access the Jupyer Notebook from your web browser, but running all software in Docker.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>This sounds all very exciting!</div></div></blockquote><div><br></div><div>Sure!<br></div><div><br></div></div></div></div>