Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for Core: local::lib #16479

Open
p5pRT opened this issue Mar 26, 2018 · 10 comments
Open

Request for Core: local::lib #16479

p5pRT opened this issue Mar 26, 2018 · 10 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Mar 26, 2018

Migrated from rt.perl.org#133029 (status was 'open')

Searchable as RT133029$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 26, 2018

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 8, 2018

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.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Apr 8, 2018

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

@khwilliamson
Copy link
Contributor

@khwilliamson khwilliamson commented Apr 17, 2022

@Grinnz do you want to bring this up again?

@Leont
Copy link
Contributor

@Leont Leont commented Apr 17, 2022

@haarg ^

@Grinnz
Copy link
Contributor

@Grinnz Grinnz commented Apr 18, 2022

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

@demerphq
Copy link
Contributor

@demerphq demerphq commented Apr 18, 2022

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.

@haarg
Copy link
Contributor

@haarg haarg commented Apr 19, 2022

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.

@Leont
Copy link
Contributor

@Leont Leont commented Apr 23, 2022

I agree with the above.

@demerphq
Copy link
Contributor

@demerphq demerphq commented Apr 24, 2022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants