From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Docker and singularity containers Date: Wed, 12 Sep 2018 22:59:33 +0200 Message-ID: <87bm92jutm.fsf@elephly.net> References: <20180912151616.iwt3kqb77zd76wf6@thebird.nl> <878t4662lw.fsf@gnu.org> <87in3ak3w1.fsf@elephly.net> <20180912183059.oto5gi36boo62sx2@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0CEl-0006FO-RH for guix-devel@gnu.org; Wed, 12 Sep 2018 16:59:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0CEh-0004xy-LP for guix-devel@gnu.org; Wed, 12 Sep 2018 16:59:47 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21137) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g0CEh-0004ws-7x for guix-devel@gnu.org; Wed, 12 Sep 2018 16:59:43 -0400 In-reply-to: <20180912183059.oto5gi36boo62sx2@thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pjotr Prins Cc: guix-devel , Ludovic =?utf-8?Q?Court=C3=A8s?= 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