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