From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Blog: Guix packaging tutorial Date: Thu, 13 Sep 2018 14:04:55 +0200 Message-ID: <20180913120455.ahdepkvfi6y7jwsk@thebird.nl> References: <87in397jsd.fsf@ambrevar.xyz> <8736udk40j.fsf@elephly.net> 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]:36019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0QMq-00025l-P8 for guix-devel@gnu.org; Thu, 13 Sep 2018 08:05:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0QMp-0000vr-0o for guix-devel@gnu.org; Thu, 13 Sep 2018 08:05:04 -0400 Content-Disposition: inline In-Reply-To: <8736udk40j.fsf@elephly.net> 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" To: Ricardo Wurmus Cc: guix-devel , guix-blog@gnu.org On Thu, Sep 13, 2018 at 01:53:16PM +0200, Ricardo Wurmus wrote: > > 1. General > > Go through the various fields of the `package` record. > > GUIX_PACKAGE_PATH, `guix build` and `guix package`. >=20 > I have mixed feelings about recommending GUIX_PACKAGE_PATH to new > contributors. I think that generally it is better to guide them to > working on a git checkout directly, because moving packages from a > separate GUIX_PACKAGE_PATH module to Guix proper isn=E2=80=99t friction= less. Yes, the GUIX_PACKAGE_PATH serves a different purpose. Main thing you want to capture is package definitions and perhaps the workflow of submitting a patch. > Maybe also mention the recursive importers to automate a large part of > the work for packages from Pypi, CRAN, Bioconductor, etc. >=20 > > I'm mostly wondering whether the GNU build system should be introduce= d > > before the trivial build system: it's simpler and would let the user > > have a first package ready within minutes with fewer lines of code to > > understand; conversely, it also means that we would first take some > > black-box systems for granted ("What the hell happens under the hood?= ", > > might some readers wonder) which would only be explained later. >=20 > In my opinion, the power of abstraction over conventional build systems > is very impressive. Instead of having to write a shell snippet that > does =E2=80=9C./configure --prefix=3D/foo && make && make install=E2=80= =9D you can lean > back and use =E2=80=9Cgnu-build-system=E2=80=9D instead. And it is less specialized. Hard coding configure options is the road to madness - at least where it comes to targetting multiple outputs. That is where packaging systems like conda fall short. > From there it=E2=80=99s easy to talk about packages that *don=E2=80=99t= * use > conventional build systems or that otherwise deviate from conventions, > which is one reason for using modify-phases. A second advanced hacking tutorial could discuss more advanced features. Pj.