[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ripit/perl: use perl_cddb_get package?

From: Sam
Subject: Re: ripit/perl: use perl_cddb_get package?
Date: Wed, 18 Dec 2019 15:22:38 +0100
User-agent: K-9 Mail for Android

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 <address@hidden>:
>> This seems to be the problem, it returned:
>> $ perl -E 'map say, grep -d, @INC'
>> $ find /gnu/store/*perl* -iname ""
>> /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/
>> /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/
>> 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
>* 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]