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.
Related
Given a particular module that used to be supported as part of Perl core, how do I tell if it's supported by the Perl version I want to upgrade to?
perlpolicy says
As of Perl 5.12, deprecated features and modules warn the user as they're used.
There's the deprecate module which provides this warning. A module is deprecated for at least one cycle before it's actually removed. That doesn't help much if you skip over several perl versions.
Module::CoreList tracks deprecated modules too.
The fallback is reading the perldelta pages to find the changes between the version they are using and the version they want to upgrade too.
I'm have Perl 5.8 installed on all of our servers and wanted to use the DBI and DBD::Oracle modules to access our databases. My main concern is with the newer versions of perl the DBI and DBD modules will stop working with 5.8. Then I'd have to upgrade every server to the newest perl version.
My question is as perl itself becomes later versions and modules are developed for them will they still be backwards compatible? "CPAN does not carry all ancient releases and patchlevels of Perl", if I create documentation saying run "cpan -i DBI" if the newest version of DBI will not function with 5.8?
There is no guarantee.
In general, you want to use the same versions of the modules on all your systems. If you use different versions then you will have different bugs and features available on different servers.
I'd suggest creating Debs / RPMS / etc for the ones you are going to use and then run a package repository that all your servers share.
Not absolutely, but in general perl is pretty gentle about breaking code, with not many breaking changes, and long deprecation cycles on the ones that do happen. A pretty hefty portion of the code that was uploaded to CPAN in 1999 will run without modification in perl 5.14.
Since perl 5.12, the perl release cycle has become shorter, and the deprecation periods have also become shorter, which is cause for concern, but at the same time the concept of feature versioning has gained currency. The idea is that code may declare the version of perl that it's targeting with use VERSION (e.g. use 5.16.0), and any code that doesn't declare a version is assumed to be targeting approximately 5.10. When code that targets an older perl version is run on a newer perl version, newer features that might cause compatibility issues (e.g. new keywords) are disabled, and old misfeatures may be re-enabled in the name of compatibility. This isn't an absolute guarantee, but it will be adhered to as much as practical.
More information about back-compatibility and deprecation is in perlpolicy.
In general, no. There are a lot of great new features in recent releases of Perl (smart match operator, the // operator, for two one example) that are not backwards compatible. Many authors will decide to take advantage of these features rather than keep their modules compatible with older versions of Perl.
Check the CPAN Tester's Matrix of a module, including the link about the max version that passes all of the distribution's tests, to get an idea of what versions of Perl are compatible with each version of a module.
cpan -i Some::Module will indeed attempt to install the latest version of the module Some::Module, but with a little research, it can be used to install older versions too. You need to find or guess the author of an older version and provide the path to the distribution on the CPAN mirror servers. For example,
cpan -i J/JF/JFRIEDL/Yahoo-Search-1.9.12.tar.gz
cpan -i A/AS/ASG/List-Gen-0.80.tar.gz
CPAN authors may delete their older distributions from CPAN. But even then, the distribution is available at the BackPAN if you're willing to download, unpack, and build the distribution yourself.
What is a "dual-life" module? It's mentioned in the perldelta for Perl 5.14.
Dual life modules are modules that exist in two disconnected source repositories, commonly meaning both in the Perl core (those libraries distributed with perl), and on CPAN.
The CPAN version may be updated more frequently than the core version. The core version may have been tested on more platforms.
In the context of the link you gave, "adding as a dual-life module" means forking the CPAN distribution, possibly making some changes (such as normalizing documentation or licensing), and incorporating that fork into the core perl repository. This means that this module will now be installed by default when anyone installs this version of perl.
A dual-lived module is one that is found both in the perl distribution and in its own distribution (on CPAN). For example, Data::Dumper is part of the perl distribution and the Data-Dumper distribution. On the other hand, IPC::Open3 is only available as part of the perl distribution, so it's not dual-lived.
The advantage of a dual-lived module (these and these) is that it can be upgraded without upgrading Perl.
If you wanted to upgrade a core module that isn't dual-lived (these), then you have to upgrade all of Perl.
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?
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