Hello all.
Feedback offered herein to the Queue readers by another user (NOT a
maintainer, at this time) of the ExtUtils-Install modules (there are 3:
Install.pm, Installed.pm, Packlist.pm), in reply to:
[Sat Nov 26 08:02:08 2011] MCAST:
["ExtUtils::Installed fails to read packlist for relative @INC elements"]
Show quoted text> The symptom is that packlists loaded from relative @INC elements contain
> no keys.
I would want there to be no packlists searched for any relative path spec
found in @INC. The concept of "installed" that is explicit in the tool
we are
addressing, ExtUtils::Installed, implies to me that one desires the code to
locate and return results pertaining to *installed* package files; e.g. ones
which most reasonable invocations of the perl interpreter will find when the
"require" or "use" directive is invoked. A path spec in an arbitrary
place in
the filesystem is not, by definition, reliably "installed." A relative path
depends on the cwd which is by definition, again, arbitrary.
I wouldn't know, at this time, how to explain that more clearly.
Show quoted text> This occurred for me after "use lib 't/tlib'" but I believe some people
> use non-absolute paths in PERL5LIB for production code, not least q{.}.
> These are fine until @INC is used after chdir.
[...]
As someone who develops on Open Source *nix-like OSes and M$WhyneDos, I have
clearly got too limited experience to know whether that is *ever* true
or not.
In my work, the only relative path spec that ever appears in @INC in
production code is ".", the current directory, and it is there only
because by
default, perl appends it to @INC. It was never reasonable for
ExtUtils::Installed to search "." as part of the codepath for discovering
*installed* modules. In fact it is a bug that has existed for a long time
since the module was first released as part of the Perl Toolchain, that is
would fail to skip "." (see more below). It would, by extension, not be
reasonable [or let's say desirable just so I can *sound* reasonable]) for
EU::Installed to search any relative path spec whatsoever.
Although (at time of this writing) there's no sync between the CPAN code and
the Perl core code ...the Perl core from for ex. 5.16.1 has a revision of
EU::Installed that adds a new parameter for the constructor: skip_cwd ...and
this new parameter suggests maintainers of Perl share the view that
looking in
the (arbitrary) "." pathspec is undesirable (or, perhaps more
realistically --
since it wasn't made a default -- we can say that "they demonstrate the
awareness that some people have been complaining"). See
http://perldoc.perl.org/5.16.1/ExtUtils/Installed.html
In summary:
Aside from the odd contortions that go hand in hand with writing test
code for
releases of perl modules (all bets are off, there), I can see no
rationalization for wanting EU::Installed to be changed so as to return
populated packlist objects for relative (and therefore arbitrary) path spec
-based searches.
If EU::Installed was changed to support in any sense what the OP seems
to have
wanted, *I* would in turn feel obliged to start making bug reports *against*
such changes. And EU::Installed is part of the Perl core distribution
as part
of the Perl Toolchain that is relied upon to "install" reusable Perl
(library)
modules. It has long been integral with, for example, the workings of
EU::MakeMaker. As such it is appropriate to take a strict view of what the
module does and how it does it. Regarding it as a general-purpose tool for
reporting or manipulating any files related to Perl in anyone's (possibly
idiosyncratic) notion of what needs to be located, is not an approach
that is
compatible with its role in the larger "CORE" context.
Show quoted text> [Sadly for my use, ExtUtils::Installed would be ideal but the large I/O
> burden and very likely lack of .packlist files (e.g. in binary-installed
> Perls) mean I need a different solution anyway. Thank you for providing
> it, and I hope this is useful.]
I believe that this is the right conclusion for you to have reached, even if
for reasons that as given, I don't all agree with, and I wish you luck.
--
somian ^AT^ CPAN -DOT- org
Also email somian08 ^AT^ gmail -DOT- com.
