[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Docker and singularity containers
From: |
Pjotr Prins |
Subject: |
Re: Docker and singularity containers |
Date: |
Thu, 13 Sep 2018 08:10:36 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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.