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.
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.
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.
I frequently use the cpan upgrade command to bring my Perl modules to their latest versions. Regrettably on distributions like CentOS which use ancient versions of Perl it attempts to upgrade perl itself along with other modules like B::X. Is there some way I could combine the ease and power of upgrade but not attempt (and fail) at upgrading core modules? Thank you.
Don't use the system perl. Install your own and start from that. Even when there isn't an ancient perl.
You will have to exclude not just core modules, but also distributions that depend on newer versions of core modules, and distributions that depend on those distributions...
It's a battle you can't win and shouldn't even try to.
BTW, the CPAN-trying-to-upgrade-perl bug was really really ancient; are you really seeing it?
This is probably a multi-part question. Background: we have a native (c++) library that is part of our application and we have managed to use SWIG to generate a perl wrapper for this library. We'd now like to distribute this perl module as part of our application.
My first question - how should I distribute this module? Is there a standard way to package pre-built perl modules? I know there is ppm for the ActiveState distro, but I also need to distribute this for linux systems. I'm not even sure what files are required to distribute, but I'm guessing it's the pm and so files, at a minimum.
My next question - it looks like I might need to build my module project for each version of perl that I want to support. How do I know which perl versions I should build for? Are there any standard guidelines... or better yet, a way to build a package that will work with multiple versions of perl?
Sorry if my questions make no sense - I'm fairly new to the compiled module aspects of perl.
CLARIFICATION: the underlying compiled source is proprietary (closed source), so I can't just ship source code and the appropriate make artifacts for the package. Wish I could, but it's not going to happen in this case. Thus, I need a sane scheme for packaging prebuilt binary files for my module.
I look after DBD::Informix, one of the Perl Database Driver modules that works with the DBI (Perl Database Interface). The underlying libraries used to connect to IBM Informix Dynamic Server (IDS) are proprietary, but the DBD::Informix code itself is not. I distribute that code on CPAN, just the same as any other Perl module. People can download that source, and (provided that they have the Informix ClientSDK installed on their machine - and Perl and DBI and so on), they can build DBD::Informix to work with their installed Perl.
I would strongly counsel that you arrange that your Perl interface code be made available in source form, even though the library that it interfaces to is proprietary. This allows people to install the code with any version of Perl they have - without requiring you to deal with inconsistencies.
If you still want to provide binary support, you are going to have to work out which platforms you want to support, and build the module with the standard version of Perl on each such platform. This gets messy. You need access to an instance of each machine. Granted, virtual machines make this easier, but it is still fiddly and the number of platforms and versions only grows. But you still need to support people who don't use the standard version of Perl on their machine - that's why the Perl wrapper interface needs to be provided in source form.
DISCLAIMER: I have next to no experience creating binary packages that can easily be installed. Therefore, I am making this post CW to make it easier for others to add their advice.
You should make the distribution available in source form so it can be compiled on each system tailored according to the specifics of that system. I really like Module::Build for that purpose.
For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6. Package both 32-bit and 64-bit versions for each of 5.6, 5.8 and 5.10. Use the version of mingw you can install using ppm to compile the modules to preserve binary compatibility.
Another option is to use PAR::Packer and distribute your application in a PAR archive. In that context, PAR::WebStart might be useful although I have not tried it. I have had success with PAR archives in the past, though.