Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How are Perl's core libraries managed?

Tags:

perl

perl-core

From my understanding Perl traditionally has only included core functionality, and people install additional libraries to do all sorts of useful (and sometimes very basic) things. But at some point there came to be "core libraries" which are shipped with Perl by default – so you can use these libraries without installing them.

Coming from Python I'm curious how this is managed. Specifically:

  1. How are libraries chosen?
  2. Do the libraries still have their own version numbers and release schedules?
  3. What kind of backward-compatibility guarantees do you have when using these libraries?
  4. Is it common to upgrade or downgrade these libraries in a system? Is this done system-wide or more specifically?
  5. If there's a bug fix that requires an API change, how does that happen?
  6. How is functionality added to these core libraries (if it is at all)?
like image 796
Ian Bicking Avatar asked Jun 03 '10 16:06

Ian Bicking


People also ask

How CPAN works?

CPAN, the Comprehensive Perl Archive Network is the system that makes these available for others to download and install. CPAN uses PAUSE's permissions data to determine if a given release contains unauthorized packages.

What is libraries in Perl?

A library is a collection of loosely related functions designed to be used by other programs. It lacks the rigorous semantics of a Perl module. The file extension . pl indicates that it's a Perl library file.

What is a Perl distribution?

In Perl a true value is any value that is not: null, zero or a zero-length string. A distribution is a collection of files that usually includes a Perl module and several other files.


1 Answers

  1. Currently, only libraries that are necessary to bootstrap/install other libraries go into the core list.
  2. Some are only in the Perl git repository. Some are dual-life on CPAN and in the repo. Sometimes bugs get fixed in the repo and the changes are backported to the CPAN version. Sometimes there's a new release on CPAN and a Perl maintainer checks in the module into the repo.
  3. You can rely on a core module. There's an very lengthy deprecation timespan before one gets removed, recent prominent example was Switch.
  4. Packagers (e.g. the people who build RPMs for a Linux distribution) never could get this right; the wrong order of include paths (@INC) not their fault, and finally fixed with 5.12. This is the reason where the recommendation comes from to compile your own perl and not mess with the system installation. With 5.12, you are supposed to just use CPAN to install an upgraded version of a core module, and it gets installed addtionally to the one shipped with the system, but since the new one comes before the old one in the include path, the new one gets loaded when you use/require it.
  5. Laid out in perlpolicy.
  6. Program the functionality and tests for it, document the thing, then release on CPAN or respectively have a maintainer apply the changeset. This is accompanied with a discussion on p5p.
like image 103
daxim Avatar answered Oct 28 '22 04:10

daxim