Skip Menu |

This queue is for tickets about the local-lib CPAN distribution.

Report information
The Basics
Id: 66552
Status: resolved
Priority: 0/
Queue: local-lib

People
Owner: apeiron [...] cpan.org
Requestors: Smylers [...] stripey.com
willert [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.008004
Fixed in: 2.000003



Subject: Ommission in the documentation
It is obvious once you think about it, but it should be noted in LIMITATIONS nonetheless: when used in code as in the SYNOPSIS or via $ perl -Mlocal::lib=[PATH] script.pl the original versions of some core modules like Cwd, File::Spec, File::Path and Carp will be used. Normally this is no problem -- and can't be fixed easily anyways without bundling your own versions of those in a special namespace -- but might cause weird bugs down the road. This bit me hard when trying to use File::Remove, that depends on a File::Path version that is core since 5.8.9 on perl 5.8.7 ... [don't ask for details ;)] How to reproduce (Ubuntu 10.10, perl 5.10.1): $ perl -E 'use File::Path; say $File::Path::VERSION' 2.07_03 $ cpanm -q -Lextlib File::Path Successfully installed File-Path-2.08 (upgraded from 2.07_03) 1 distribution installed $ perl -Mlocal::lib=extlib -E 'use File::Path; say $File::Path::VERSION' 2.07_03 $ eval $( perl -Mlocal::lib=extlib ) $ perl -E 'use File::Path; say $File::Path::VERSION' 2.08
This report is unclear. I'm going to have to ask what you told me not to ask about to understand this. It presently sounds like a case of "well don't do that, then" but I'm not sure.
Show quoted text
> It presently sounds like a case of "well don't do > that, then" but I'm not sure.
Exactly, it is a "don't do that" and should be noted in the LIMITATIONS section of the documentation. Maybe like: --- Be aware that local::lib loads a few core modules before it can do its job when used as a module (either as in the SYNOPSIS or via 'perl -Mlocal::lib=~/perl5' script.pl). This will cause some dual-life modules from the local lib to be ignored in favor of the system versions, causing problems with older perl's. To avoid that, use the shell version instead.
Sorry it's taken so long for me to get back to this. Can you submit a docpatch?
On Wed Jul 13 22:29:56 2011, APEIRON wrote: Show quoted text
> Sorry it's taken so long for me to get back to this. Can you submit a > docpatch?
After all that time, I'm not sure what the issue was, or what I was talking about, but from what I can gather from the thread, I already gave you a text snippet you can just past into the POD. After letting this issue hanging out to dry for a few months you could as well just paste the section above into the LIMITATIONS POD. Saves us both the trouble to try to understand what was going on ... again ... ;) Cheers, Sebatstian
Subject: local::lib Loads Old File::Spec
Date: Wed, 9 Oct 2013 11:49:52 +0100
To: bug-local-lib [...] rt.cpan.org
From: Smylers <Smylers [...] stripey.com>
Hi. Because local::lib itself uses File::Spec, it can't be used inside a program to provide a newer version, such as in: use local::lib; use File::Spec 3.40; If your Perl comes with File::Spec 3.33 then local::lib will load that, and because 3.33 is already loaded, perl won't find the 3.40 which is now in @INC. It would be helpful to have this limitation documented. File::Spec was the one that bit me, but I'm guessing it applies to the other modules local::lib uses too. It doesn't happen if local::lib environment variables are set, but sometimes that isn't convenient. Some workarounds and more detail here: http://blogs.perl.org/users/smylers/2013/10/locallib-and-filespec.html Thanks. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
Subject: Re: [rt.cpan.org #89363] local::lib Loads Old File::Spec
Date: Wed, 9 Oct 2013 12:16:38 +0100
To: Bugs in local-lib via RT <bug-local-lib [...] rt.cpan.org>
From: Smylers <Smylers [...] stripey.com>
I just wrote: Show quoted text
> It would be helpful to have this limitation documented.
Or, alternatively, to document that it isn't intended to use local::lib like that in the first place, and that if you want a Perl program to use a particular local::lib directory without relying on environment variables being set, the way of doing that for a local::lib directory called foo is: use lib 'foo/perl5/lib'; Either way, please can we document something which avoids anybody else having to learn this the hard way. Thanks. Smylers -- Stop drug companies hiding negative research results. Sign the AllTrials petition to get all clinical research results published. Read more: http://www.alltrials.net/blog/the-alltrials-campaign/
I've added a note to the limitations section about problems using local::lib inside a script. Changing local::lib to not load File::Spec isn't really workable, but I prevented local::lib from loading a couple other modules that would have similar problems. Included in dev release 2.000_000.
Resolved in 2.000003
local::lib has now been changed to not use File::Spec in 2.000010, so the workarounds for this shouldn't be needed.