Why is nothing found in @INC path ?!?!

[filter_at_stevenstromer_dot_com]

Hi,

I'm trying to build a CGI PerL web app hosted on Fedora/Apache machine,
making XML requests to a Windows/IIS machine (No, I have no choice in
this matter; we're trying to connect to QuickBooks).

I get an Internal Server Error when trying to execute the PERL script
via a web browser, and when I try to run the executable from the
command line using the format ./[script.cgi] I get the error "Can't
locate SOAP/Lite.pm in @INC".

Fundamentally, I understand that CPAN uses paths under @INC to locate
modules that have been installed. I did nothing special when installing
SOAP::Lite; I just used 'install SOAP::Lite' at the CPAN prompt. The
installation completed without error. However, when I list installed
modules with 'perldoc perllocal', I do not see the SOAP::Lite module
listed.

A little further delving indicates that during the SOAP::Lite install
MIME::Tools is not found, even though the install seems to complete
successfully. So, I try to install MIME::Tools. This utterly fails
because IO/Wrap.pl is not locatable in @INC. IO/Wrap.pl is a part of
IO::Wrap. So, I try to install IO::Wrap, only to learn that this has
already been installed.

So far, I don't like CPAN or PerL. I am not certain whether this is a
problem with CPAN, SOAP::Lite, or me.

Plese help.

Thanks!

Steven Stromer

[harryfmudd [AT] comcast [DOT] net]

filter_at_stevenstromer_dot_com wrote:

> Hi,
>
> I'm trying to build a CGI PerL web app hosted on Fedora/Apache machine,
> making XML requests to a Windows/IIS machine (No, I have no choice in
> this matter; we're trying to connect to QuickBooks).

I don't know what PerL is, but I assume you mean Perl.

>
> I get an Internal Server Error when trying to execute the PERL script
> via a web browser, and when I try to run the executable from the
> command line using the format ./[script.cgi] I get the error "Can't
> locate SOAP/Lite.pm in @INC".
>
> Fundamentally, I understand that CPAN uses paths under @INC to locate
> modules that have been installed. I did nothing special when installing
> SOAP::Lite; I just used 'install SOAP::Lite' at the CPAN prompt. The
> installation completed without error. However, when I list installed
> modules with 'perldoc perllocal', I do not see the SOAP::Lite module
> listed.

Well, What actually happens is that Perl uses @INC to find the modules -
CPAN is simply a Perl module.

>
> A little further delving indicates that during the SOAP::Lite install
> MIME::Tools is not found, even though the install seems to complete
> successfully. So, I try to install MIME::Tools. This utterly fails
> because IO/Wrap.pl is not locatable in @INC. IO/Wrap.pl is a part of
> IO::Wrap. So, I try to install IO::Wrap, only to learn that this has
> already been installed.

This sounds like you didn't get an install. In fact, it sounds like you
didn't get anything much. When you ask CPAN to install something, the
first thing it does is to check to see if you have all the
prerequisites. If you do not, it asks if you want to install the missing
ones. This is not an automatic "yes". An update a couple weeks ago
claimed I was missing Win32API::File, and asked if I wanted it
installed. I didn't think it had much chance of succeeding under Darwin,
so I said "no". CPAN said "fine", and did my install without it. All the
self-tests worked, so I assumed it was a fluke of some sort.

You won't find IO/Wrap.pl anywhere in @INC. But you _should_ find
IO/Wrap.pm, if IO::Wrap is really installed.

>
> So far, I don't like CPAN or PerL. I am not certain whether this is a
> problem with CPAN, SOAP::Lite, or me.

OK. I personally have no problems with CPAN or SOAP::Lite, so let's see
where that leaves us.

Did CPAN tell you it installed anything? If it didn't, it didn't. There
was a guy a month or so ago who simply insisted that CPAN had installed
his module "because it didn't tell him it didn't." It might help if you
would post the actual CPAN output involved.

Is it possible there is more than one version of Perl involved? There's
no law against having more than one copy of Perl on your system. I do,
because I didn't want to be stuck with the ancient Perl that came with
my system, but I also didn't want to risk clobbering the manufacturer's
installs.

If you're using the 'cpan' script, check its shebang line to make sure
it's what you expect. Or run cpan the hard way by

$ perl -MCPAN -e shell

Or both.

Well, I lie about having no problems with SOAP::Lite. The last
SOAP::Lite update appears to have dropped the version numbers from about
three modules: Apache::SOAP, SOAP::Client, and SOAP::Packager - so CPAN
finds a couple old distributions with higher version numbers for these
modules, and recommends you install them. Don't.

Tom Wyant

[filter_at_stevenstromer_dot_com]

Thank you for responding to my posting.

After some reading, I think I know what I need to be asking more
explicitly. While it is clear that cpan.pm does it's best to offer up
correct dependencies, it occasionally lists module dependencies that
are either not appropriate for a particular case, or that put one into
a loop of uneasibly fulfillable dependencies. In other words. cpan.pm
isn't all-knowing, isn't correct 100% of the time, and does not
successfully complete installation of requested modules and their
dependency fulfilling brethren every time.

Thus, my first question is, is there an order of installation of module
bundles and stand-alone modules that will help to reduce the chances of
a 'higher-level' module installation failure?

My second question is, has it been know to happen that a module IS
SUCCESSFULLY INSTALLED using all the default responses to all
installation and configuration options, but is not installed into a
default @INC path?

Third question. If so, would the best solution to this problem be to
(a) add the install path to the @INC configuration, (b) to manually
install the module into one of the default @INC paths, or (c) would
this be considered a reportable bug that should be brought to a
maintainer's attention?

Fourth question. If the case described in question two IS possible, why
would this happen in an package management environ like CPAN, where
standardization seems such a desireable goal? This seems to hold
especially true for such a broadly installed module as SOAP::Lite.

Fifth question. I note that my @INC paths include directory trees under
'site-perl' and 'vendor-perl', in addition to the version (x.x.x)
directory tree. Can you explain the significance of these branches?

Sixth question. You mention that I should check the shebang line of the
cpan script. When I vi
/usr/lib/perl5/vendor_perl/5.8.6/LWP/Protocol/cpan.pm, the first line
reads: "package LWP::Protocol::cpan;". I don't see a shebang line. Am I
missing something here? I mean, cpan.pm does seem to be working, as I
have installed a few modules successfully in the recent past.

Thanks for your assistance. I hope that other Perl/CPAN newbies find
these questions and your responses useful.

[blmarsh@gmail.com]

filter_at_stevenstromer_dot_com wrote:

> Thank you for responding to my posting.
>
> After some reading, I think I know what I need to be asking more
> explicitly. While it is clear that cpan.pm does it's best to offer up
> correct dependencies, it occasionally lists module dependencies that
> are either not appropriate for a particular case, or that put one into
> a loop of uneasibly fulfillable dependencies. In other words. cpan.pm
> isn't all-knowing, isn't correct 100% of the time, and does not
> successfully complete installation of requested modules and their
> dependency fulfilling brethren every time.
>
> Thus, my first question is, is there an order of installation of module
> bundles and stand-alone modules that will help to reduce the chances of
> a 'higher-level' module installation failure?
>
> My second question is, has it been know to happen that a module IS
> SUCCESSFULLY INSTALLED using all the default responses to all
> installation and configuration options, but is not installed into a
> default @INC path?

Not in my experience. I seemed to have some problems on Windows but
these were fixed by updating the CPAN module to the latest version
thusly

$ perl -MCPAN -e shell
....lots of output...
cpan> install Bundle::CPAN
....lots of output...
cpan> reload CPAN

> Sixth question. You mention that I should check the shebang line of the
> cpan script. When I vi
> /usr/lib/perl5/vendor_perl/5.8.6/LWP/Protocol/cpan.pm, the first line
> reads: "package LWP::Protocol::cpan;". I don't see a shebang line. Am I
> missing something here? I mean, cpan.pm does seem to be working, as I
> have installed a few modules successfully in the recent past.

No shebang line in perl modules (ie files ending in .pm)

The CPAN module that you use to install modules is CPAN.pm file
somewhere in @INC paths with one of its first lines reading:

package CPAN;

Can you do me a favour?

Try typing at the shell prompt:

perl -MSoap::Lite -e "1;"

Is an error message printed on the terminal?

and

find / -name Lite.pm

This one will do a search for Lite.pm on the filesystem and hopefully
tell you where it was put if it was successfully installed. Remember
that the Lite.pm that you are looking for will have the word Soap in
its path and start with the line

package Soap::Lite;

Also, you could perhaps load the Soap::Lite RPM distribution. It seems
there is an RPM in Dag Wieers RPM repository. I would add the
repository to the yum configuration and do:

yum update
yum install perl-SOAP-Lite

[sstromer@gmail.com]

Thank you for responding. Regarding:

$ perl -MCPAN -e shell
cpan> install Bundle::CPAN
cpan> reload CPAN

I did this when I realized I was not getting a successful install of
SOAP::Lite. Earlier the same day, I installed XML::LibXSLT and other
modules with no problem.

Next,
perl -MSoap::Lite -e "1;" returns:

Can't locate Soap/Lite.pm in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/5.8.6 .).
BEGIN failed--compilation aborted.

Next,
find / -name Lite.pm -print returns:

/root/.cpan/build/SOAP-Lite-0.67/blib/lib/XML/Parser/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/blib/lib/Apache/XMLRPC/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/blib/lib/SOAP/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/blib/lib/OldDocs/SOAP/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/blib/lib/XMLRPC/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/blib/lib/UDDI/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/XML/Parser/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/Apache/XMLRPC/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/SOAP/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/OldDocs/SOAP/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/XMLRPC/Lite.pm
/root/.cpan/build/SOAP-Lite-0.67/lib/UDDI/Lite.pm

Clearly, no success. As i describe in an earlier posting, cpan.pm's
logging shows that wrap.pm is not being located in @INC, which
SOAP::Lite seems to need for a successful install. Attempts to install
IO::Wrap to resolve this problem fail with yet more missing
dependencies.

I understand that using an RPM is an option. I'm just trying to learn
how to work with Perl modules correctly because there are many that I
am going to need for the project I'm working on, and I don't want to
muddle things up even more before I understand them. Thanks so much for
the help!

[harryfmudd [AT] comcast [DOT] net]

filter_at_stevenstromer_dot_com wrote:

<snip!>

>
> Sixth question. You mention that I should check the shebang line of the
> cpan script. When I vi
> /usr/lib/perl5/vendor_perl/5.8.6/LWP/Protocol/cpan.pm, the first line
> reads: "package LWP::Protocol::cpan;". I don't see a shebang line. Am I
> missing something here? I mean, cpan.pm does seem to be working, as I
> have installed a few modules successfully in the recent past.

By "the cpan" script, I did _not_ mean CPAN.pm - I meant 'cpan', as
reported by (e.g.) 'which cpan'. The question was pursuant to figuring
out whether you have more than one Perl installed on your system.

When I troubleshoot, one of the things I do is look at the problem from
the other side, and try to imagine how I would _cause_ the problem. One
way to do it would be to have two copies of Perl installed (say,
/usr/bin/perl and /usr/local/bin/perl, to take a not-so-random example).

Then, if 'perl' launched one of these, but if 'cpan' launched the other
(via its shebang line), you would get the symptoms you describe: cpan
installs SOAP::Lite successfully, but 'perl -MSOAP::Lite -e 1' can't
find it.

Tom Wyant