Thank you for your time, but I am afraid I have wasted it. The perl module dirs are set in a env variable in bash's files, and for that reason my fish couldn't find them. (Also the syntax isn't compatible so I you to copy them out, which is quite annoying). So in a way it's fixed now ^^" Thanks anyway!
Am 9. November 2019 12:24:58 MEZ schrieb Marc Chantreux <e...@phear.org>: >> This seems to be the problem, it returned: >> $ perl -E 'map say, grep -d, @INC' >> $ find /gnu/store/*perl* -iname "CDDB_get.pm" >> /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm >> /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm > >> So it seems like the problem is that this perl script package can't see the >> installed perl modules? > >yes: every module have its own store so perl don't see them >ok. i don't know enough of guix to help on it but from the perl >perspective, a module is available is in @INC which contains: > >* a built-in list of standard directories >* the list of directories provided by the $PERL5LIB env variable > (the awesome local::lib module is very helpful to manage $PERL* > variables: don't miss it) >* the list of directories hardcoded in the script using `use lib` > instruction > >if guix wants to compete with (or encapsulate) cpan tooling, it needs to >have a way to embrace the 2 most common strategies to install the >things > >* installing everything in a directory dedicated for the software > (this clear separation with the base system and other programs > makes it easy to install, remove, maintain without breaking anything > on the host... like containers does) > >* installing as much as possible in the standard directories using > system packages. > >it would be very good to reach the point when the combo >perlbrew+cpanm+local::lib (or carton) could be replaced by a guix >counterpart. this is probably the momentum i'm waiting for to replace >my perl toolchain with guix. > >for the projects providing cpanfiles, a strategy could be to provide >both a perl version and the installed modules from the perl cpanm >commands in the same store? > >also: having a plan9 experience, i would like to arg that the better way >to do that is having a single dir to bind everything we need in it. >that's basically what docker does poorly but i have no experience in >handmade linux namespaces > >> Any input is appreciated. > >i can help as "someone who knows the perl ecosystem practices" but >i don't know enough about guix. > >regards >marc > >
