Re: potluck in the house

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

> This is an update on "guix potluck", an attempt to support a more
> decentralized way of developing Guix packages, as a complement to the
> main package set.
>
> I have a number of packages that I never packaged for external use, at
> least beyond putting them in a git repo somewhere.  Here's an example of
> packaging one of these with guix potluck.  Guile-Present is a library
> that lets you write presentations in Texinfo and uses Cairo to render
> nthat to slides.

Turns out Guile-Present is already in Guix proper, but Guile-JPEG isn’t!
:-)

> I dug up the repo and pushed it to gitlab at
> https://gitlab.com/wingo/guile-present.  Then in the root directory of
> that checkout I ran:
>
>   guix potluck init
>
> and it carps, saying
>
>   guix potluck init: wrong number of arguments
>   usage: guix potluck init [OPT...] REMOTE-GIT-URL
>   Try 'guix potluck --help' for more information.
>
> If you run help you see you need a URL for the public git repo.  Cool, I
> have that:
>
>   guix potluck init https://gitlab.com/wingo/guile-present
>
> Now it says:
>
>   guix potluck: error: init: missing --build-system; try --build-system=help 
> for options

[...]

>   guix potluck init --autotools --license=lgpl3+ 
> https://gitlab.com/wingo/guile-present
>
> And voilà:
>
>   Cloning into '/tmp/guix-directory.861r57/git-checkout'...  done.
>   Creating guix-potluck/
>   Creating guix-potluck/README.md
>   Creating guix-potluck/guile-present.scm
>
>   Done.  Now open guix-potluck/guile-present.scm in your editor, fill out its 
> "synopsis"
>   and "description" fields, add dependencies to the 'inputs' field, and try to
>   build with
>
>     guix build --file=guix-potluck/guile-present.scm
>
>   When you get that working, commit your results to git via:
>
>     git add guix-potluck && git commit -m 'Add initial Guix potluck files.'
>
>   Once you push them out, add your dish to the communal potluck by running:
>
>     guix potluck update https://gitlab.com/wingo/guile-present master

Pretty cool!  I’m sure some of this could make sense for generic Guix
packages too.

> It builds, which is pretty cool.  (The wip-potluck branch extends guix
> build -f to recognize potluck packages.)

Oh I see, I was wondering why that was working.  :-)

Maybe we could have ‘guix potluck build’ or something?

> By default it connects to guix-potluck.org; you can use --host to
> specify a different host.  All connections to the potluck host are over
> HTTPS.  OK it spews some trash on stdout:
>
>   ERROR: In procedure get-bytevector-n:
>   ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum The TLS 
> connection was non-properly terminated.> read_from_session_record_port)'.
>
> I don't understand this entirely; shouldn't nginx be terminating things
> fine?  I have never used the HTTP client with HTTPS though.

We’d have to debug it, but (guix build download) works fine.

> Anyway, fine.  So the server received this request, checked out that git
> repo and branch, looked for potluck packages in guix-potluck/, and added
> those packages to a "source" git repo:

Woow, that’s the really cool part.

>   (define-module (gnu packages potluck 
> https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
>     #:pure
>     #:use-module ((guile) #:select (list quote define-public))
>     #:use-module ((guix packages) #:select (package origin base32))
>     #:use-module ((guix git-download) #:select (git-fetch git-reference))
>     #:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
>     #:use-module ((guix build-system gnu) #:select (gnu-build-system))
>     #:use-module ((gnu packages pkg-config) #:select (%pkg-config))
>     #:use-module ((gnu packages texinfo) #:select (texinfo))
>     #:use-module ((gnu packages autotools) #:select (libtool automake 
> autoconf))
>     #:use-module ((gnu packages gtk) #:select (guile-cairo))
>     #:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))

Since #:select doesn’t play well with circular dependencies among
modules, we should probably avoid it for the (gnu packages potluck …)
modules.

Also, I wonder if this should use ‘specification->package’ for packages
provided by Guix?

> Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
> It's effectively a "channel" managed by "guix potluck host-channel"
> running on guix-potluck.org.  If you have a checkout of this repo, you
> can build Guile-Present just via "guix build -L /path/to/target/checkout
> guile-jpeg".  Pretty cool, right??!!!?!?!

Pretty cool, indeed!

The nice thing is that we can pretty much unleash it on Guile users very
soon!

> Incidentally here is the configuration for that server:

We should add a potluck server service in GuixSD, too, so that this
config can be shrinked, and to make it easier to run a potluck server.

> Hi!  You scrolled down all this way, congratulations!
>
> So, remaining tasks to do:
>
>   (1) All of this is currently in a WIP branch, wip-potluck.  I need to
>       submit to upstream.  It needs some documentation too.
>
>   (2) The host-channel facilities run user-supplied Scheme code.  To do
>       so safely, that needs sandbox facilities from Guile.  That will
>       need Guile 2.2.1.  For the time being I have disabled the server.

Given that ‘potluck-package’ is very declarative, I was wondering
whether it would be simpler to simply interpret it as data (have a
‘potluck-sexp->package’ compiler), as opposed to setting up a sandbox
with a white-list of bindings.  Of course inert data is not as nice as
something programmable, but in this case it looks like users would not
really depart from what the default template.  Thoughts?

Anyway, that’s really an “implementation detail.”

>   (3) Someone needs to design and implement a "guix channel" facility to
>       take advantage of this branch :)  Until then, GUIX_PACKAGE_PATH
>       and the -L argument are the things to use.
>
>   (4) Probably we need a story about what happens when Guix updates.  We
>       can compile target repositories for Guix dev and also for Guix
>       stable branches, understanding that maybe packages move around to
>       different modules during Guix development.
>
>   (5) We need the main https://guix-potluck.org/ to show progress on the
>       work queue.
>
>   (6) We will need better facilities for updating potluck packages to
>       new repository versions.  Maybe this is what "guix package update"
>       should do and the notify-the-server thing should be called
>       something else.
>
> I think that's it though for an MVP.  What do yall think?

I think it’s awesome, and the development pace is impressive.

I was wondering about #1 and whether it should be in Guile or in Guix,
but it’s probably technically more convenient to keep it in Guix.

Now, I realize that none of it is Guile-specific, is it?  So there’s the
question of the effect it can have on contributions to Guix proper.
It’s probably OK as long as there’s enough value in using the reviewed
packages that are in Guix itself.  Thoughts?

Thank you!

Ludo’.