Re: guix is the guildhall that we always wanted!

[Andy Wingo]

On Fri 17 Mar 2017 14:54, Christopher Allan Webber <address@hidden> writes:

> Andy Wingo writes:
>
>> On Thu 16 Mar 2017 23:01, Mark H Weaver <address@hidden> 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 "address@hidden")))

  (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