I'm trying to install WWW::Mechanize; but of course, something had to go wrong. I purchased a VPS, and whenever I load up CPAN (AKA The quick way), it says I'm missing modules. Such as... HTTP, LWP, Test, HTML, LOADS of things that I thought would come standard with a perl installation. I tried doing a few of them one by one, but they all fell like a stack of dominos. I don't even think my perl installation has most of the core modules.
For example... Trying to install LWP:
HTTP::Status
HTTP::Negotiate
HTML::Entities
HTTP::Daemon
HTML::HeadParser
HTTP::Cookies
HTTP::Request::Common
HTTP::Response
HTTP::Request
Says I need those modules; and then when I install those, it's basically an endless cycle with errors being returned and failed tests.
Installation of HTTP::Message:
IO::Uncompress::Inflate
IO::Uncompress::Gunzip
IO::Compress::Gzip
IO::Uncompress::RawInflate
Compress::Raw::Zlib
IO::Compress::Deflate
HTML::Parser
IO::Compress::Bzip2
IO::Uncompress::Bunzip2
TL;DR: Can't install standard modules, returns fail. Doesn't even have extremely common modules.
Keeping the core distribution as small and light as possible is beneficial, as Perl is used in many situations with varying amounts of space.
You haven't mentioned any modules that are actually core, nor your Perl version, nor your OS version/distribution (which some I have understood don't actually distribute a full Perl installation themselves). If you find out for sure that this is actually the case, it's an issue with your distribution, and you should bring it up with them.
You also haven't actually asked a question anywhere.
Just install what you need, when you need it.
Edited for your edit: The first block of modules you listed is not core. The second block is partially core since 5.9.4, and partially since 5.10.1.
IO::Uncompress::Inflate was first released with perl 5.009004
IO::Uncompress::Gunzip was first released with perl 5.009004
IO::Compress::Gzip was first released with perl 5.009004
IO::Uncompress::RawInflate was first released with perl 5.009004
Compress::Raw::Zlib was first released with perl 5.009004
IO::Compress::Deflate was first released with perl 5.009004
IO::Compress::Bzip2 was first released with perl 5.010001
IO::Uncompress::Bunzip2 was first released with perl 5.010001
You still haven't mentioned an OS distribution/version, a Perl version, or provided the error messages you receive. The cpan command-line or commands you're using would help, too.
What Linux distribution? If Debian/Ubuntu you will want to install the build-essential package via aptitude for make and friends. I'm sure RPM based distros would have similar packages available as well.
What are the actual errors you are getting? Have you tried installing a small no non-core dependencies distribution like Try::Tiny manually to see what fails?
Related
For example I believe that the Encode module is considered a core module and shipped with every copy of Perl. It has its own page on Perldoc:
https://perldoc.perl.org/Encode.html
...but it is also available on CPAN:
http://search.cpan.org/~dankogai/Encode-2.92/Encode.pm
From skimming the two documents, it seems that they contain the same text. So why put it in both places? Is it just so that CPAN can be used to lookup documentation on "any Perl module"?
Such modules are said to be "dual-life" modules.
So users can upgrade the module without upgrading perl itself.
So developers can release fixes and updates to the module on a different schedule (e.g. more often) than perl itself.
Or maybe the module started on CPAN, and it was later added to the perl distro (e.g. because a module in the tool chain requires it).
Or maybe the module is in the process of being removed from the Perl distro.
Also making a core library available at CPAN allows to easily upgrade from the version shipped with Perl to get the latest improvements and bug fixes.
For example, Encode versions shipped with some versions of perl:
Perl Encode
v5.22.4 2.72_01
v5.24.2 2.80_01
v5.26.1 2.88
(retrieved with corelist -a Encode). Any of these can be readily updated to the latest Encode 2.92.
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I'd like to install a Perl module (in this case, FindBin), but since it is included in the Perl 5.10.1 distribution, cpan wants to install Perl 5.10 for me. Is there a way of installing just the module via cpan?
The only option that I can see is installing directly from source, which seems a bit crude as there is no separate package (for example, Makefile.PL, etc.), just the bare .pm file.
Since this is a small module that only has the one file, it's doable in this case, but what if I wanted to install a much larger package?
EDIT: This is somewhat aside from the original question, but speaks to the general issue of modules being packaged up with Perl distributions: I discovered that the "standalone" FindBin (version 1.49) had a syntactic error, so I retrieved version 1.50 out of the Perl 5.10.1 distribution... However since the module is now listed on CPAN as part of Perl 5.10, I am unable to find the CHANGES file describing what was changed/fixed in this delta. Is it reasonable that I should have to go into the developer repository to pull out this information?)
EDIT 2. Okay, here's a better example. On Perl 5.8.8 I have version 1.04 of Carp. However, I see that Perl 5.10.1 comes packaged with version 1.11. Is there a way of getting CPAN to install the latest version of Carp for me without dragging in all of Perl 5.10.1? I can't even find a link to the Carp module on CPAN except to the perl 5.10.1 installation.
> corelist FindBin
FindBin was first released with perl 5.00307
Which version of Perl do you use that does not include FindBin? If you use at least Perl 5.6.0 (all versions before are considered deprecated), you have no need to install FindBin. If you have anything older, I suggest an upgrade to 5.6.2/5.8.9/5.10.1.
Kurila is not a "standalone" FindBin, it's a dialect of Perl. FindBin is not a dual life and is released only bundled with Perl. You can consider releasing FindBin to CPAN as standalone distribution - it is easy if you used ExtUtils::MakeMaker in past.
Latest useful change of FindBin was on 2007-04-28, related to VMS. Latest useful non-VMS change was on 2006-10-25.
Things you can try include
Dropping FindBin.pm into the same directory as your executable and using use FindBin
Dropping FindBin.pm into your Perl library directory
Using the source code of the module in your script
I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my #INC path. I don't mind compiling my own mod_perl.
Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0
Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:
/usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs
Install and configure mod_perl like normal.
It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:
export PATH=/usr/local/perl/5.10.0/bin:$PATH
You'll want to look into mod_so
I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.
I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.
Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.
It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.
I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.
If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.