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? Thanks for the review, `~Eric
