Re: potluck in the house

[Andy Wingo]

Hi :)

On Thu 13 Apr 2017 17:42, address@hidden (Ludovic Courtès) writes:

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

Oh neat :)

>> (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?

We could, but I was getting a bit overloaded with all the config options
you might want (substitutes, grafts, input replacements, etc) so I just
extended "build".  To do so, you just have to make the environment in
which the file is loaded also have the "potluck-package" and
"potluck-source" bindings, and then add another special case along with
package? / derivation? / etc.  WDYT?  OK or not the right thing?

>> 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.

Is this still the case?  With Guile 2.2 we fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15540 so maybe this isn't
a problem.

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

It certainly could, and indeed it could do so for all packages.
Currently it uses specification->package only if it can't resolve the
module in which a package is exported at compile-time.  I think this
probably leads to better run-time overhead when the files are compiled
to .go and a package graph that makes more sense but I don't know.

>> 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!

Guix users I guess you mean? :)  There is of course nothing
Guile-specific in this facility.  But yeah as a solution to the Guile
"CPAN problem", yes definitely!

>> 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.

Yes, and improve the nginx configuration, and add a fcgiwrap service,
and add a git http service... :)

>>   (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.”

Yeah I don't know.  I thought that would maybe be good but then it's
also kinda cool that we provide a capability for abstraction in these
package definitions.  I can imagine interesting extensions given that
it's a programming language rather than data.  And this way we do take
advantage of cheap syntax checking via macros, pushing people to program
Scheme, and it's nice to be able to paste these definitions into a REPL
too... and we certainly want the record type!

I see what you are saying but since it doesn't seem to be necessary I am
tempted to punt, given that we can get Guix-on-Guile-2.2.1 out very soon
(a couple weeks maybe?).

> 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?

Yes I wonder about this.  I think overall it would increase the speed at
which packages go upstream to Guix, because people can have a feel that
a package is well-tested in a channel and when they start to depend on
it they want it upstream.  It's possible that some packages go the other
way (especially packages with few users and no depending packages) but I
suspect that the majority of flow will go Guix-ward.  And it's nice to
know that you have a working package definition produced by a machine --
there are many automation possibilities to make review easier.

I don't understand the dependency situation though.  What happens when
someone makes a glibc potluck package?  That wouldn't affect the static
links in Guix deps but it might affect the command line, depending on
how we make it happen.

I think we should make it so that the lower-potluck-package process
prefers "core" packages if available, and only goes to the channel if
the core does not provide a package matching the specification.

I think this is a question for the design of channels though: how to
resolve dynamically scoped (specification->package) links in the
presence of channels.

Andy