Hello! Pierre Neidhardt <m...@ambrevar.xyz> skribis:
>> s/conventionally.*/typically used for read-only global variables/ > > But aren't they generated in scope? I think we should mention this, or else > new users try to access them out of scope. I’m not sure what you mean by “generated in scope”. The ‘%’ convention is just a convention (and Andy and I realized a while back we interpreted the convention differently :-)) so we shouldn’t draw too much from that. Regarding ‘%build-inputs’ and ‘%outputs’, I think it’s enough to say that these are global variables. Whether they are in scope depends on whether a local variable shadows them. Does that make sense? >> It doesn’t make much sense to propagate a tarball, does it? > > Not really, but I just wanted to use "propagated input". We need a better > example. Any idea? The typical example are C, Python, or Guile libraries that propagate libraries they depend on. Another option is to skip propagated inputs altogether. Thoughts? >> > The astute reader may have noticed the quasi-quote and comma syntax in the >> > argument field. Indeed, the build code in the package declaration should >> > not be >> > evaluated on the client side, but only when passed to the Guix daemon. >> > This >> > mechanism of passing code around two running processes is called >> > [[https://arxiv.org/abs/1709.00833][code staging]]. >> > See >> > [[https://www.gnu.org/software/guix/manual/en/html_node/G_002dExpressions.html][the >> > "G-Expressions" chapter]] from the manual. >> >> Though precisely package definitions don’t use gexps yet… Not sure if >> we should mention it; maybe it’s outside the scope of this tutorial. > > Hmmm... I think it's important to mention why code is not evaluated. Maybe > this > rather obscure paragraph could be simplified? > I'll remove the mention to G-exp, it does not belong here indeed. I think it’s good to mention code staging and the fact that there’s “build-side code”, but the G-Expressions chapter says more than this, which could be confusing. >> > See https://guix.info/contact/ for the mailing lists, IRC, etc. >> >> For now please use gnu.org/software/guix URLs. > > Ok for this one, but I'd also like to link to the channels section in the > manual, but it's not on gnu.org. Or is it? Not yet. So yeah, you can use guix.info for this one if you need it. > Last but not least, what should I do next? Should we wait for more reviews? > Should I go ahead and push to master? I suppose you can push to guix-artwork.git master; Ricardo? Please try to use tags already used by the other articles. When would you like it to be on line? Thanks, Ludo’.