Re: Blog: Guix packaging tutorial

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Pierre Neidhardt <mail@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’.