Eric Bavier <bav...@member.fsf.org> skribis: > On Sat, 14 Feb 2015 00:15:22 +0100 > l...@gnu.org (Ludovic Courtès) wrote: > >> Eric Bavier <bav...@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’.
