[GRASS-dev] New attempt to update GRASS for Mac

[Vaclav Petras]

On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug <rainer_krug at icloud.com> wrote:

> On 19 Jul 2017, at 21:54, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
> On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton <Michael.Barton at asu.edu>
> wrote:
>
>>
>> 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.
>>
>
> We don't have an official GRASS Docker image. Maybe it wouldn't be even
> that advantageous for open science purposes.
>
>
> 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 (https://hub.docker.com/r/rock
> er/geospatial/) 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.
>
> 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).
>

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.

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.


> Anyway, we have already many Dockerfiles. See for example one from me
> which I created for reproducibility of my recent paper:
>
> https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile
>
> 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.
>
>
> 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?
>

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.

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.)


>
>
> 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.
>
>
> 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
> https://hub.docker.com/r/rocker/rstudio/.
>

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).


>
> 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?
>

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.)


> That should not be a problem at all with a Docker image?
>

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.


>
> This sounds all very exciting!
>

Sure!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170721/65649445/attachment.html>