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