Generalizing DAG rewriting

[Ludovic Courtès]

Hi!

Ricardo Wurmus <address@hidden> skribis:

> Myles English <address@hidden> writes:
>
>> Hello Fede, Eric,
>>
>> on [2017-02-07] at 15:15 Federico Beffa writes:

[...]

>>> it seems that the only Python specific part of
>>> 'package-with-explicit-python' is the keyword '#:python'. What do you
>>> think of generalizing it by making it a function keyword argument and
>>> move the procedure to its own module (maybe (guix build-system
>>> utils)?).
>>
>> ...I came the same conclusion as Fede: it could be generalised.  It is
>> probably close to working for me (with respect to ghc) so I will keep
>> going for now.  I am not competent enough to generalise it but if
>> someone else does I can help test it.
>
> I’m doing the same for some Perl packages.  I defined a procedure
> “package-for-perl-5.14” which takes a package and rewrites it.
>
> It looks like this:
>
> (define (package-for-perl-5.14 pkg)
>   (let* ((rewriter (package-input-rewriting `((,perl . ,perl-5.14))
>                                             perl-5.14-package-name))
>          (new (rewriter pkg)))
>     (package
>      (inherit new)
>      (arguments `(#:perl ,perl-5.14
>                   ,@(package-arguments new))))))
>
> The problem here is that it doesn’t rewrite the “#:perl” argument
> recursively, so the dependencies of a Perl package will still refer to
> the latest version of Perl as that’s what’s used in the build system.
>
> We would need a solution that would take care of this problem for all
> build systems.

I agree that this is asking for generalization.

Another instance of DAG rewriting is the ‘package-with-’ helpers in
(guix build-system gnu).

We should have a general form of transformation procedure that handles
DAG traversal and memoization like all these procedures do.

Ludo’.