On Jun 10, 2004, at 6:06 PM, John Horner wrote:
This may be a frequently-asked question, but I've got installed modules which CPAN says are "up to date" but Perl can't find.
@INC contains: /System/Library/Perl/5.8.1/darwin-thread-multi-2level
... snip ...
but when I look for HTML::TokeParser, I find it in
/Library/Perl/darwin/HTML/TokeParser.pm
/Library/Perl/darwin is the architecture-specific directory for Perl 5.6 on Jaguar and older. Modules found there will not be compatible with the 5.8.1 version of Perl that you're using.
so what should I do? I can't see exactly how CPAN (or a previous version of it) decided on that as the install location -- can I change the Config for CPAN to fix that?
A previous version of Perl (correctly!) decided on that, not a previous version of CPAN. (The difference is a bit academic, I know, because CPAN.pm is bundled with Perl...) You cannot fix it because it is not broken.
I know, of course, that I can have "use lib" to add that to @INC for each script, and I could presumably hack that for the Terminal environment somehow, but I'd rather not -- can I force that into @INC in some kind of system-wide way?
You could, but that wouldn't allow Perl 5.8.1 to use modules compiled for 5.6. There is a reason that some modules are kept in version- and architecture-specific directories - they don't work with other Perl versions or architectures.
One more question, sorry -- if I just copied the TokeParser.pm into the right dir, somewhere Perl *is* looking for it, would that be a problem?
Yes. For one thing, there's more to this module than just the .pm file - there's also a .bundle, and there might be some autoload (.al) files or affiliated module (.pm) files as well.
Assuming that modules are pure-perl
That's an invalid assumption. The architecture-specific subdirectory exists for the purpose of providing a separate location for modules that are *not* pure-perl. Since HTML::TokeParser is in that directory, you should assume it's *not* pure-perl, but has an XS (i.e. a compiled C) component as well as Perl.
Modules that are compiled for different major versions of Perl (5.6 vs. 5.8), and/or for different architectures (darwin vs. darwin-thread-multi-2level) are *not* compatible with other versions and/or architectures. So even if you did go to the trouble of figuring out what files to move, moving them wouldn't do any good.
I should just reinstall?
I'd use a scalpel first, and save the axe for a last resort. ;-)
The key question is why the CPAN tool is claiming that this module is up to date when in fact it is not. How are you starting it, with 'cpan' or with 'perl -MCPAN -e shell'? Whichever one you're using, try the other to see if you get the same results. Is there a PERL5LIB in your environment?
That's key - you need to understand that the module is *not* in an incorrect location. It's in the correct location for the Perl it was installed under, and your current Perl avoids looking in that location for a good reason. Nothing is broken in that regard. What you need to figure out is why the CPAN shell is finding that module when it shouldn't.
sherm--
