From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: guix is the guildhall that we always wanted! Date: Fri, 17 Mar 2017 15:26:55 +0100 Message-ID: <874lysm11s.fsf@igalia.com> References: <87zigl3wph.fsf@pobox.com> <87a88kanjq.fsf@netris.org> <87efxwnw3x.fsf@igalia.com> <87lgs480vv.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cosqV-0007Fj-Vu for guix-devel@gnu.org; Fri, 17 Mar 2017 10:27:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cosqU-0001jR-WA for guix-devel@gnu.org; Fri, 17 Mar 2017 10:27:12 -0400 In-Reply-To: <87lgs480vv.fsf@dustycloud.org> (Christopher Allan Webber's message of "Fri, 17 Mar 2017 08:54:12 -0500") 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: Christopher Allan Webber Cc: guix-devel@gnu.org, guile-user@gnu.org On Fri 17 Mar 2017 14:54, Christopher Allan Webber writes: > Andy Wingo writes: > >> On Thu 16 Mar 2017 23:01, Mark H Weaver writes: >> >>> If [Guix] starts encouraging a decentralized approach, that would >>> result in strong pressure on us to freeze our API, which includes even >>> such details as which module each package is exported from. This >>> would drastically reduce the freedom Guix has to evolve the way its >>> packages are specified. >> >> I get what you are saying. I think that if a future guildhall is >> decentralized but uses Guix it needs to minimize its burden on Guix. >> That could mean that the packages are actually specified in a different >> DSL with different stability characteristics -- for example that DSL >> could call specification->package under the hood for example, like >> Ludovic mentions. (I should mention that this idea of using Guix and >> especially all its errors are my own -- haven't talked to others about >> it yet!) >> >> Which module a package definition is in is a good example of something >> not to depend on. > > This makes sense to me... if it really is true that our scheme'y > Guildhall-style packages are so simple they're more data than code, > maybe we could even restrict them to... just data. Just a list of what > files are being provided, etc. That could easily be stored in some > minimal database. Concretly I would propose something like this in a package.scm in the git repo: (use-modules (guildhall)) ; or whatever we call it (import-guix-packages ((a "a") (b "b@5.2"))) (define foo (guildhall-package (name "foo") (inputs `(("a" ,a) ("b" ,b))) (git-url "https://github.com/foo/foo") (home-page "https://github.com/foo/foo") (synopsis "Foo is a thing") (build-system simple-guile-build-system) (description "It's a thing") (license license:expat))) I guess you would not want to load this file from the web service as it has arbitrary Scheme code inside it. I could see solutions where only the end-user tool loads this file and exports data to the server, and the server creates an appropriate "normal" package definition using just the Guix API. It can write those definitions out to disk. It would export a progressing git repository of Guix package definitions. As Guix API changes, that server could re-render those package descriptions. Of course that only works in some limited cases. Otherwise you as a user could do this rendering process for packages you are developing. Maybe it is a good thing to encourage nontrivial packages to go upstream to Guix. There's not a whole lot that is Guile-specific there of course. Maybe this is just an exurb of Guix; I don't know. Probably "foo" might need a local build story as well and this doesn't naturally solve that. More thinking to do here! Andy