From @Grinnz

I would like to request that local​::lib be considered for inclusion in core
as a dual-life module. My reasoning is twofold​:

1. IMO, Modules should be cored when they provide essential or ubiquitous
functionality for usage of Perl. This decreases the difficulty of getting
started when new to the language. (I am open to debate on this opinion or
overrule by the pumpking.) local​::lib is essential for developing in Perl
when using a system-managed or root-installed installation of Perl, either
when you lack permissions or in order to avoid changing the modules a
system-managed Perl expects to find globally.

2. local​::lib is used by CPAN.pm when using the -I option, and should be
used when installing modules without permissions to install to
privlib/sitelib.

I am aware of multiple simple ways to bootstrap local​::lib installation,
but the purpose of this request is so that this step will not be needed in
the future when assisting people new to Perl.

-Dan

From @xsawyerx

On Mon, 26 Mar 2018 10​:36​:03 -0700, grinnz@​gmail.com wrote​:

I would like to request that local​::lib be considered for inclusion in core
as a dual-life module. My reasoning is twofold​:

I don't object to this. The code doesn't seem to have changed recently so it might be at a good point. What I would be interested in is​:

1. Hearing from the current maintainer(s).
2. Knowing there is more than one person who could work on it if something breaks.
3. Knowing we could add P5P to co-maint in case any porter needs to make a release and maintainers are unavailable.

The RT System itself - Status changed from 'new' to 'open'

@Grinnz do you want to bring this up again?

@haarg ^

My opinion is unchanged from the original post, but this is largely up to @haarg

Fwiw, I am +1 on including it as dual life as @Grinnz suggests. Now that @haarg has a commit bit it makes even more sense.

I definitely think that something with roughly the capabilities of local::lib belongs in core, but I'm not certain if local::lib itself is appropriate.

There are two main ways to use local::lib. One is to set up a local lib for a project. This works reasonably well. This is often easiest to use via cpanm's -l option.

The other is to install libraries in your home directory. This is very convenient, but rather problematic for anyone with more than one perl. By default, libraries are installed using INSTALL_BASE=~/perl5, putting the .pm files in ~/perl5/lib/perl5 or ~/perl5/lib/perl5/$archname for XS modules. These paths are unversioned. This means that any time a different version of perl is used from the one which installed the modules, a crash is likely due to binary incompatibility. This is most often encountered by building and using a newer perl, installing modules into a local::lib in your home directory, and having any OS provided programs using a #!/usr/bin/perl shebang being broken. This is why perlbrew does not use the default local::lib setup, but creates isolated local libs for each perl installed.

This default setup is what CPAN.pm encourages, and how cpanm acts if it can't write to the standard install locations. And I'm hesitant to change it due to backwards compatibility. If I did try to fix it, it would probably involve passing lots of options to ExtUtils::MakeMaker (or MB) to install into a versioned subdirectory, which perl would pick up automatically. EUMM and MB do not have any reasonable support for doing this type of installation.

There are other horrible things local::lib has to do internally for some cases. Since local::lib is meant to set up the path to load modules, it can't load any modules that could be in that local lib directory. This includes all dual-life modules. So it can't use Cwd.pm to find the current working directory. Instead, it has to re-execute perl so it can load Cwd.pm without interfering with the current process. It also has to re-implement parts of File::Spec. And I have no idea what happens if you try to use it on a system like VMS.

I feel like a core implementation of the local::lib concept could improve on these issues. For a comparison, python's PEP-0370 covers the user directory use case. python includes user directories in its search path by default.

I agree with the above.