I know I often shouldn't, but I use the Perl 5 installed through Ubuntu packages for most of my local development. I could maintain a parallel installation myself, but I have better things to do. (I do have bleadperl available if I need it.)
Every time I get a new machine, or perform an OS upgrade which changes the major version of Perl 5, I have to reconfigure the CPAN client to install distributions from the CPAN appropriately.
That's ridiculous, for two reasons.
First, the CPAN.pm configuration has traditionally asked too many questions. I understand that it's nice to have configurability and the ability to run on all sorts of platforms with odd behaviors and strange utilities and baffling constraints, but I also think it's plausible to assume that most new installations of Perl 5 on a modern Unix-like system can speak HTTP, for example.
The second problem is that the Perl 5 version has come from a system package — a .deb file, in my case — and the CPAN client prefers to install tarballs from the CPAN itself.
Even though Debian and Ubuntu packagers (especially the admirable Debian Perl Group) have made plenty of CPAN distributions available as .debs, I have to configure my CPAN client myself, and it does not work with the system package manager.
There's no reason it couldn't.
Imagine that the system Perl 5 included in the default package (or included an optional package) which had a CPAN client configured appropriately. It has selected an appropriate mirror (or uses the redirector). It knows about installation paths. It understands how to use LWP or
curl to download tarballs. It requires a
make utility and the Perl 5 development headers.
Why stop there? There could be an alternate package (or an alternate Perl 5 installation or a program to switch paths) which set up local::lib for each user to install modules without overwriting the global installation.
Go another step further. A system such as Debian or Ubuntu or Fedora or one of the BSDs may include OS packages of CPAN distributions. If you want to install WWW::Mechanize, why can't a custom CPAN subclass translate that into a request to install
libwww-mechanize-perl through the packaging system if it's available?
I realize that plenty of experienced Perl 5 developers dislike the idea of giving up control over every aspect of their own installations. That's fine. They can keep that control. Improving the defaults of the Perl 5 experience does not have to mean removing customization possibilities for experts.
The Perl 5 community has to produce at least three artifacts before this is possible:
- An agreement that it's okay for distributions to customize their CPAN client configurations at installation time.
- A set of guidelines for how to do so safely—probably backed up by code.
- The will to improve the experience of installing, maintaining, and upgrading modules from CPAN distributions, especially for novices.
Each goal is achievable, though the latter likely requires the active Perl 5 community to refuse to support specific vendor customizations in any official capacity.
The result—a Perl 5 that's easier to develop, easier to begin, and exactly as customizable as it is now—is better for everyone.