all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ben Woodcroft <b.woodcroft@uq.edu.au>
To: "Ludovic Courtès" <ludo@gnu.org>,
	"Pjotr Prins" <pjotr.public12@thebird.nl>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: [PATCH] Add python2-seqmagick.
Date: Tue, 22 Sep 2015 08:36:03 +1000	[thread overview]
Message-ID: <56008653.9060607@uq.edu.au> (raw)
In-Reply-To: <87eghrlpi8.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3950 bytes --]

On 22/09/15 02:13, Ludovic Courtès wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>
>> This contains the most lucid description of 'inputs' I have yet seen.
>> Could they go into the main Guix documentation?
> What do you think needs to be changed compared to the text at
> <http://www.gnu.org/software/guix/manual/html_node/package-Reference.html>?
So, those descriptions are right?

The manual from the POV of someone a bit confused:
||
>
> |inputs| (default: |'()|)
>
>     Package or derivation inputs to the build. This is a list of
>     lists, where each list has the name of the input (a string) as its
>     first element, a package or derivation object as its second
>     element, and optionally the name of the output of the package or
>     derivation that should be used, which defaults to |"out"|.
>
That paragraph doesn't tell me much about what inputs actually are in 
any detail, only the semantics of how to specify them.
> |propagated-inputs| (default: |'()|)
>
>     This field is like |inputs|, but the specified packages will be
>     force-installed alongside the package they belong to (see |guix
>     package|
>     <http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#package_002dcmd_002dpropagated_002dinputs>,
>     for information on how |guix package| deals with propagated inputs.)
>
I guess it is initially confusing why propagated-inputs exist as a 
concept - I presumed that inputs were "installed" too (an input of my 
input is my input). "force-install" is a bit ambiguous - force installed 
in the profile? in the store? What is "forced" - isn't every input 
required? What is the meaning of "install" exactly?
>
>     For example this is necessary when a library needs headers of
>     another library to compile, or needs another shared library to be
>     linked alongside itself when a program wants to link to it.
>
So I'm guessing this is supposed to mean that if library (A) needs 
headers of another library (B) when trying to compile (C) which requires 
(A), then library B should be in the propagated-inputs list of library 
A? This doesn't seem to have anything to do with being force installed. 
Also, an example from an interpreted language would be useful. 
Particularly since there seems to be some discussion about this on the 
mailing list atm.
http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00597.html
> |native-inputs| (default: |'()|)
>
>     This field is like |inputs|, but in case of a cross-compilation it
>     will be ensured that packages for the architecture of the build
>     machine are present, such that executables from them can be used
>     during the build.
>
>     This is typically where you would list tools needed at build time
>     but not at run time, such as Autoconf, Automake, pkg-config,
>     Gettext, or Bison. |guix lint| can report likely mistakes in this
>     area (see Invoking guix lint
>     <http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-lint.html#Invoking-guix-lint>).
>
>
This makes the most sense out of the three input types to me, although 
again the second sentence doesn't follow logically from the first (to 
me). Also the second sentence might include a nod to testing e.g. this 
would be where packages required only for testing are specified. Also 
unclear what mistakes lint is picking up here (how can lint know what is 
being used at runtime?), and thus the reference to lint seems of little 
benefit (authors should always run lint, so what's the point of 
mentioning it here?).

I imagine that examples would help too - the example at the top of that 
section is very useful but too simple, perhaps a second example with an 
interpreted language using different input types would be of use.
http://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html#Defining-Packages

Thanks,
ben

[-- Attachment #2: Type: text/html, Size: 5999 bytes --]

  reply	other threads:[~2015-09-21 22:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17 11:47 [PATCH] Add python2-seqmagick Ben Woodcroft
2015-09-17 15:51 ` Ricardo Wurmus
2015-09-19  9:36   ` Ben Woodcroft
2015-09-21  7:34     ` Pjotr Prins
2015-09-21 16:13       ` Ludovic Courtès
2015-09-21 22:36         ` Ben Woodcroft [this message]
2015-09-24  5:08         ` Pjotr Prins
2015-09-24  7:36           ` Ludovic Courtès
2015-09-24  8:37             ` R and R modules (and a Ruby twist) Pjotr Prins
2015-09-24  9:40               ` Ricardo Wurmus
2015-09-24 15:16                 ` Pjotr Prins
2015-09-25  9:14                   ` Ricardo Wurmus
2015-09-25 14:09     ` [PATCH] Add python2-seqmagick Ricardo Wurmus
2015-09-25 22:14       ` Ben Woodcroft
2015-09-28  9:54         ` Ricardo Wurmus
2015-09-21 22:41   ` Cyril Roelandt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56008653.9060607@uq.edu.au \
    --to=b.woodcroft@uq.edu.au \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.