potluck status

[Andy Wingo]

Hi!

To recall, "guix potluck" is a packaging facility that is a decoupled
from mainline Guix development.  The latest patches are in wip-potluck,
and a recent copy of the patches is here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26645

Here is part of the documentation in that branch:

  5.15 Invoking ‘guix potluck’
  ============================

       Note: As of version 0.12.0, this tool is experimental.  The
       interface is subject to radical change in the future.

     Guix is developed as a unified project composed of both the package
  manager and the set of packages.  This allows Guix to evolve while
  remaining healthy and coherent.  If there is a change that needs to be
  done across Guix’s entire tree, Guix developers can make it happen.  One
  way in which this principle manifests itself is in the ‘package’ data
  type, where input packages are directly specified by value in the
  ‘inputs’, ‘native-inputs’, and ‘propagated-inputs’ fields, instead of
  being specified as some abstract package name and version constraint
  that Guix would have to solve for.  *Note package Reference::, for more
  on the ‘package’ data type.

     However it is sometimes desirable to develop a package or set of
  packages in a more decoupled way, for example when a package set is
  still incubating or when a package is inappropriate for sending upstream
  for some reason.  Such packages use Guix and extend Guix but are not a
  part of the Guix project, properly speaking.  As such, they need to be
  resilient to changes in upstream Guix.  It would be brittle if such a
  package definition had to reference a Guix package by value; the Scheme
  variable denoting the upstream Guix package might move to a different
  module, or be renamed, or changed in some unexpected way.

     Guix’s “potluck” facility fills this gap.  A “potluck package” is
  like a normal Guix package, except it expresses its inputs in the form
  of package specifications instead of direct references.  *Note
  potluck-package Reference::.  Potluck packages also have a simpler
  package structure with fewer fields; compared to normal Guix packages,
  they are less expressive but more isolated from details of upstream
  Guix.

     The user interface to potluck packages is concentrated in the ‘guix
  potluck’ command.  To begin, let’s say you are a developer of the ‘foo’
  project, and you’d like to package ‘foo’ for use in your Guix system and
  maybe also that of a friend.  You’re not sure if you want to support it
  yet so you don’t want to make a proper release, but there should be
  something in the middle between that and not packaging it at all.  You
  decide to give ‘guix potluck’ a go.

     So in that git checkout, you run ‘guix potluck init URL’, where URL
  is a publicly accessible git URL at which ‘foo’ is hosted.  ‘guix
  potluck init’ takes the following options:

  ‘--build-system=SYS’
  ‘--build-system=help’
  ‘--autotools’
       Indicate that the package uses the build system named SYS.  Pass
       ‘help’ as the build system to see available options.  ‘--autotools’
       is like the common ‘--build-system=gnu’, but additionally
       indicating that an ‘autoreconf’ step is needed before building.
  ‘--license=LICENSE’
  ‘--license=help’
       Specify the license of the project.

     Calling ‘guix potluck init’ will result in the creation of a
  ‘guix-potluck’ directory in your git checkout, containing a brief
  overview ‘README.md’ file as well as a ‘foo.scm’ potluck package
  definition.  *Note potluck-package Reference::.  Just fill in the
  synopsis and description and add the inputs and you have the beginnings
  of a potluck package.

     You can try building your new package by running ‘guix build -f
  guix-potluck/foo.scm’.  Once that works, you can share the file with
  your friends and they can build your package too.

     Of course, it would be nice if you could share that package with the
  world.  And it would be nice if your potluck package definitions could
  augment the set of available packages and versions.  And it would be
  nice if your potluck package could serve as a first draft of a proper
  Guix package definition.  We agree completely!

     Guix’s potluck facility also implements a kind of registry of potluck
  recipes, as if it were hosting an actual potluck.  This ‘host-channel’
  facility takes requests to add potluck packages and translates that into
  a git repository of all potluck packages, as well as a git repository of
  Guix packages compiled from those potluck packages.

     To inform a channel host of the presence of fresh tasty potluck
  dishes, run ‘guix potluck update URL BRANCH’.  URL should be the URL of
  a git repository containing a ‘guix-potluck’ directory, and BRANCH is a
  ref in that repository.  By default, the request is made to add the
  package to the default ‘guix-potluck.org’ host; pass ‘--host=HOST’ to
  specify an alternate registry.

     Running ‘guix potluck update’ will simply enqueue an update request
  on the server.  Visit ‘https://HOST/’ in your browser to see the state
  of the work queue, and to see whether your package update actually
  succeeded.  If it does succeed, you should be able to check out the git
  repository conventionally hosted at ‘https://HOST/git/main.git’, add
  that checkout to your ‘GUIX_PACKAGE_PATH’, and thereby have access to
  that package.  In the future this will be made easier with a ‘guix
  channel’ facility, but for now you have to use ‘GUIX_PACKAGE_PATH’ or
  similar.  *Note Defining Packages::, for more information.

     Finally, there is the code that actually runs the potluck service:
  ‘guix potluck host-channel’.  This tool will host a web server on
  localhost, listening on port 8080 by default.  It expects to be behind
  some kind of HTTPS terminator, like ‘nginx’.  It does the work of
  translating update requests to git repositories.  Guix includes an
  example operating system definition for a server combining HTTPS access
  to git repositories, an ‘nginx’ web front-end, and a ‘guix potluck
  host-channel’ instance.

With the release of Guile 2.2.2, I have re-enabled
https://guix-potluck.org.  I also refactored that server's configuration
to move some service definitions into Guix itself (the certbot service,
for example); see:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26684
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26685
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26686
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26687

I also updated the code for "guix potluck host-channel" to show recent
packages added, log entries, and so on.  Finally I found the source of
the HTTPS post error; it was in Guile:

  https://git.savannah.gnu.org/cgit/guile.git/commit/

With that I think I'd like to move to a "use" phase where I just sit
back and see how people use the thing :)  WDYT?  If you agree I can push
patches from the above bugs into master maybe this weekend or so.  We
can fix the "specification->package" interface in parallel as discussed
here:

  https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00401.html

when we add the "guix channel" facility, which I guess will depend on
guile-git.

Happy hacking,

Andy