[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: potluck in the house
Re: potluck in the house
Fri, 14 Apr 2017 14:54:04 +0200
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
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
>> 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 …)
> 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
>>> (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
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.