From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: [PATCH 1/2] build: Generalize 'package-with-explicit-python'. Date: Mon, 13 Feb 2017 09:28:39 +0100 Message-ID: References: <87shnm9fzo.fsf@gnu.org> 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]:56986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdC06-0004bI-EO for guix-devel@gnu.org; Mon, 13 Feb 2017 03:28:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdC05-0004Bn-6X for guix-devel@gnu.org; Mon, 13 Feb 2017 03:28:46 -0500 In-Reply-To: <87shnm9fzo.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel , ericbavier@openmailbox.org, Myles English On Fri, Feb 10, 2017 at 5:18 PM, Ludovic Court=C3=A8s wrote: > Hello! > > Federico Beffa skribis: > >> +(define* (package-with-explicit-compiler compiler bs-name >> + old-prefix new-prefix >> + #:key variant-property) >> + "Return a procedure of one argument, P. The procedure creates a pack= age >> +with the same fields as P, which is assumed a build-system named BS-NAM= E, such >> +that it is compiled with COMPILER instead. The inputs are changed recu= rsively >> +accordingly. If the name of P starts with OLD-PREFIX, this is replaced= by >> +NEW-PREFIX; otherwise, NEW-PREFIX is prepended to the name. >> + >> +When VARIANT-PROPERTY is present, it is used as a key to search for >> +pre-defined variants of this transformation recorded in the 'properties= ' field >> +of packages. The property value must be the promise of a package. Thi= s is a >> +convenient way for package writers to force the transformation to use >> +pre-defined variants." > > Great idea, along with --with-compiler. > > However, I think this: > >> + (define compiler-keyword >> + (case bs-name >> + ((haskell python emacs perl r ruby) (symbol->keyword bs-name)) >> + (else >> + (leave (_ "Operation not supported by the build system: ~A~%") b= s-name)))) > > and this: > >> + ;; Otherwise build the new package object graph. >> + ((eq? (build-system-name (package-build-system p)) bs-name) > > are kind of hacks (the build system name is supposed to be used for > debugging purposes only, and not for identification) and not very > extensible (we=E2=80=99d have to extend the =E2=80=98case=E2=80=99 above = for every new build > system.) > > What we=E2=80=99re trying to achieve here is similar to > =E2=80=98package-input-rewriting=E2=80=99 and --with-input, except that i= t should > additionally take into account implicit inputs. > > For that reason I=E2=80=99d suggest a new =E2=80=98package-input-rewritin= g*=E2=80=99 that would: > > 1. Call =E2=80=98package-input-rewriting=E2=80=99; > > 2. Change the =E2=80=98build-system=E2=80=99 field of the result and in= ject a =E2=80=9Cproxy=E2=80=9D > build system in order to be able to change the inputs of the bag > (which includes the package=E2=80=99s implicit inputs). > > Then we could change --with-input to use this new procedure, and > --with-input=3Dr=3Dmy-r would DTRT. I agree with everything you said and that's a nice plan forward. But there are other considerations as well. We have many outdated Haskell packages which do not work with the latest GHC. I'm using it and would love to see the ecosystem being upgraded, but currently can't invest enough time to do the job myself. Now, somebody offered to do the job (that's upgrading a couple 100s of packages!) and asked if tools are available to test compatibility with a new compiler. Given that we are using 'package-with-explicit-python' since 2013 and that with a simple hack we can make it work with several other build-systems, I thought that offering it as an interim solution would be simple and acceptable. As far I can see, this hack doesn't have widespread consequences and offers an immediate aid. Once the elegant and super general solution will = be ready we can easily replace it. Regards, Fede