Re: [PATCH 3/4] import: cpan: Use corelist to filter dependencies.

[ludo@gnu.org (Ludovic Courtès)]

Eric Bavier <bavier@member.fsf.org> skribis:

> On Sat, 14 Feb 2015 00:15:22 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> Eric Bavier <bavier@member.fsf.org> skribis:
>> 
>> > * guix/import/cpan.scm (%corelist): New variable.
>> >   (module->dist-name, core-module?): New procedures.
>> >   (cpan-module->sexp)[convert-inputs]: Use them.  Include "test" dependencies
>> >   in converted inputs.
>> > * doc/guix.texi (Invoking guix import)[cpan]: Mention corelist filtering.
>> 
>> [...]
>> 
>> > +(define %corelist
>> > +  (let* ((perl (with-store store
>> > +                 (derivation->output-path
>> > +                  (package-derivation store perl))))
>> > +         (core (string-append perl "/bin/corelist")))
>> > +    (and (access? core X_OK)
>> > +         core)))
>> 
>> What about adding:
>> 
>>   (warning (_ "the 'corelist' command is unavailable, not filtering modules~%"))
>> 
>> ?
>
> I like this idea.
>
>> Or perhaps it would be even better to take it from $PATH, otherwise the
>> situation could be confusing: even if Perl is installed, the user could
>> get an “unavailable” warning just because it’s not the exact same Perl.
>> 
>> WDYT?
>
> This might be reasonable if we check first that the perl versions match
> up. Otherwise the core modules might differ enough to not be helpful.
> Maybe we could try finding 'corelist' in $PATH if the current perl is
> not available in the store.  In practice we should usually have the
> most up-to-date 'corelist' in the store, if the packager is using `guix
> build` to check that the resulting recipe builds, correct?

That’s right, so perhaps my suggestion does not make much sense.

Thanks,
Ludo’.