Re: Docker and singularity containers

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Wed, Sep 12, 2018 at 10:59:33PM +0200, Ricardo Wurmus wrote:
> 
> Hi Pjotr,
> 
> >> But even this may not be enough for an on-demand service.  It might,
> >> however, be enough for a service that regularly builds packs for certain
> >> common environments from packages the build farm has already built.
> >>
> >> (This would be done with the squashfs backend, which is way faster than
> >> the Docker backend.)
> >
> > Also my original comment said to have a limited number of packages to
> > expose. I mean command line tools make sense and dedicated
> > environments. But we don't need an image for every R, Ruby and Python
> > package.

> Yes, I agree, though it may be useful to have an image containing a
> comprehensive environment for bioinformatics analysis with R, containing
> commonly used bioconductor packages; or an image with the full
> scientific Python stack.

An R.sumo would be a dream. That is coolness in the extreme. Same for
Python and Ruby.

BTW I notice Rstudio is missing in Guix. Any reason for that? 

We may be going down the Jupyter route, so it may not matter that much.

> > We should just compile a meta list of those. And if someone requests
> > one we add it.
> 
> Right.  In the meantime we may want to discuss how to implement this.
> Could it just be done as a specification for the Guix CI?  Since this
> should not be stealing resources from the build farm and thus should run
> on a separate system, how can we make sure that it only builds packs
> from packages for which we already have substitutes on the build farm?
> 
> I would gladly host a prototype of a system like this.

Excellent. We may also be able to free up resources. I'll follow up on
this.

Pj.