From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: package dependencies Date: Tue, 15 Dec 2015 11:18:31 +0100 Message-ID: <20151215101831.GA16741@thebird.nl> References: <87zixjttsa.fsf@gmail.com> <20151209201329.20594c2e@weiserose.weiserose.de> <20151210045530.GA28215@thebird.nl> <87bn9uxy0l.fsf@gnu.org> <20151214062939.GA12226@thebird.nl> <87a8pdz9sk.fsf@gnu.org> <20151214092857.GA13044@thebird.nl> <20151214193654.GA22023@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8mhc-0003E8-Kp for guix-devel@gnu.org; Tue, 15 Dec 2015 05:19:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8mhY-0001Qu-0G for guix-devel@gnu.org; Tue, 15 Dec 2015 05:19:28 -0500 Content-Disposition: inline In-Reply-To: <20151214193654.GA22023@jasmine> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Leo Famulari Cc: guix-devel@gnu.org Another way to go about this is to create a manual for packagers. My guix-notes is more general (mostly to help my memory), and then there is the wiki-thing. But I agree we don't have a very helpful starting point for packagers considering they need to learn multiple things at the same time (not least Guile ;). Pj. On Mon, Dec 14, 2015 at 02:36:54PM -0500, Leo Famulari wrote: > On Mon, Dec 14, 2015 at 10:28:57AM +0100, Pjotr Prins wrote: > > The problem with the main text is that it is written from the view > > point of technology. I would like something more human that reads lik= e > > an instruction for packagers. Be great if we had something useful > > there, otherwise questions will be asked again and again :). And I > > will have to point to guix-notes every time. >=20 > It's true, an extremely technical explanation will be completely useful > and accurate and ... it won't help many of the readers who actually nee= d > help. It is very easy to package simple programs for Guix. But I have > found that as soon as the program deviates from the Autotools or > setup.py script at all, you really need some domain-specific technical > knowledge to finish the package. I have personally learned a lot about > many subjects while packaging for Guix. >=20 > See the recent ML thread about packaging 'sent'. >=20 > >=20 > > I agree my version is less accurate, but it acts like a summing up an= d > > (actually) is precisely the way I look at these statements. We can > > have both. I am not saying we should replace your section. >=20 > I think we are all loath to include inaccuracies in the manual. But on > the other hand, I think we need to find a way to summarize the > distinction that is close to what Pjotr is proposing. >=20 > Some of us have an understanding of the subject that is directly based > on the Guix / Nix source code. The rest of us have learned by > trial-and-error and rough heuristics like Pjotr's summary (hopefully we > will all 'use the source' eventually ;) . >=20 > The difficult thing is explaining it in a way that "sets up" the reader > for further learning. You must be accurate, but you must not be too > verbose, because when you are banging your head against the wall, it is > difficult to read a long text. >=20 > The other day, this helpful jewel was shared by mark_weaver on #guix [0= ]: > fhmgufs: the distinction between build and runtime dependencies is > determined by scanning the outputs of the build for references to > /gnu/store/.... >=20 > Learning the mechanism made it clear to me. This is why Python inputs > must be propagated: there is nowhere in the main Python program to link > to dependencies in the store, so the inputs must be propagated onto > PYTHONPATH. I already understood the difference between 'native-inputs' > and 'inputs', and this doesn't really get to the heart of the > difference, but it does draw a line between them. >=20 > I propose we adapt this statement for use in the manual (assuming that > is accurate). >=20 > If there is no updated patch in a few hours, I will write one, but I > can't do it at the moment. >=20 > [0] > https://gnunet.org/bot/log/guix/2015-12-09 >=20 > PS=E2=80=94 I can't follow the "flow" of this conversation because some= people > are replying in-line while others are top-posting. Please, let's pick > one (I vote for in-line). >=20 > >=20 > > Anyway, maybe I am the only one seeing it like this. > >=20 > > Pj. > >=20 > > On Mon, Dec 14, 2015 at 09:58:19AM +0100, Ludovic Court=C3=A8s wrote: > > > Pjotr Prins skribis: > > >=20 > > > > Thanks Ludo. I still think it could be made a little clearer from= the packager's=20 > > > > perspective. How about concluding it with something like: > > > > > > > > In short, to create a package, by default you should use 'inputs'= for > > > > dependencies. Use 'native-inputs' for tools used at build-time, b= ut > > > > not at runtime and use propagated-inputs when the other two do no= t > > > > suffice. > > >=20 > > > This is certainly shorter, but the problem I have with that is that= it > > > does not accurately explain what=E2=80=99s going on. The current t= ext is > > > admittedly more verbose, but I think it is more accurate. > > >=20 > > > Hope that makes sense. > > >=20 > > > Ludo=E2=80=99. > > >=20 > >=20 > > --=20 > >=20 >=20 --=20