[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Blog: Guix packaging tutorial
From: |
Ludovic Courtès |
Subject: |
Re: Blog: Guix packaging tutorial |
Date: |
Sat, 29 Sep 2018 18:28:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hello!
Pierre Neidhardt <address@hidden> 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’.
- Re: Blog: Guix packaging tutorial, (continued)
- Re: Blog: Guix packaging tutorial, Pjotr Prins, 2018/09/13
- Re: Blog: Guix packaging tutorial, Ricardo Wurmus, 2018/09/13
- Re: Blog: Guix packaging tutorial, Andreas Enge, 2018/09/13
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/14
- Re: Blog: Guix packaging tutorial, Pjotr Prins, 2018/09/14
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/24
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/24
- Re: Blog: Guix packaging tutorial, Ludovic Courtès, 2018/09/27
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/27
- Re: Blog: Guix packaging tutorial,
Ludovic Courtès <=
- Re: Blog: Guix packaging tutorial, Ricardo Wurmus, 2018/09/29
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/30
- Re: Blog: Guix packaging tutorial, Ludovic Courtès, 2018/09/30
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/30
- Re: Blog: Guix packaging tutorial, Ludovic Courtès, 2018/09/26
- Re: Blog: Guix packaging tutorial, Pierre Neidhardt, 2018/09/26
- Re: Blog: Guix packaging tutorial, Ludovic Courtès, 2018/09/27