Re: [PATCH 1/2] build: Generalize 'package-with-explicit-python'.

[Federico Beffa]

On Fri, Feb 10, 2017 at 5:18 PM, Ludovic Courtès <address@hidden> wrote:
> Hello!
>
> Federico Beffa <address@hidden> 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 package
>> +with the same fields as P, which is assumed a build-system named BS-NAME, 
>> such
>> +that it is compiled with COMPILER instead.  The inputs are changed 
>> recursively
>> +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.  This 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~%") 
>> bs-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’d have to extend the ‘case’ above for every new build
> system.)
>
> What we’re trying to achieve here is similar to
> ‘package-input-rewriting’ and --with-input, except that it should
> additionally take into account implicit inputs.
>
> For that reason I’d suggest a new ‘package-input-rewriting*’ that would:
>
>   1. Call ‘package-input-rewriting’;
>
>   2. Change the ‘build-system’ field of the result and inject a “proxy”
>      build system in order to be able to change the inputs of the bag
>      (which includes the package’s implicit inputs).
>
> Then we could change --with-input to use this new procedure, and
> --with-input=r=my-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