Re: potluck in the house

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

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

[...]

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

That sounds like a small change to ‘guix build’ so maybe it’s OK after
all.  I’ll check the actual patch later.

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

Oh right, awesome!

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

Probably we can fine-tune that as we go.  Doing ‘specification->package’
at run time instead of compile-time would decouple things a bit more,
but maybe that’s overkill, maybe not, we’ll see.

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

Right.  We do have ‘git-daemon-service’, not sure if that’s what you
meant.

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

OK, sounds reasonable.

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

Currently the CLI would report that “glibc” is ambiguous and pick one at
random.  :-)

But yeah, there’s the question of what the potluck server should accept.
Should it reject dishes with a name that clashes with already-available
packages?  If it does, how closely should it keep track of Guix?

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

‘specification->package’ already transparently handles things in
GUIX_PACKAGE_PATH, so I suspect it wouldn’t be very different.

WDYT?

Thanks,
Ludo’.