Hi! Andy Wingo <wi...@igalia.com> skribis:
> On Thu 13 Apr 2017 17:42, l...@gnu.org (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’.
