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.
