Why no "useful" modules in the core?

schwern on 2007-07-01T20:42:10

Everyone once in a while someone says: Hey, we should ship an XML parser with Perl! Or DBI. Or Template Toolkit. Or whatever. Usually because lots of people would find that useful. And they're right, lots of people would... and lots of people wouldn't.

There's lots of old modules in the core that at some point or another someone thought it was a great idea to ship them with perl. Text::Soundex, Class::Struct, SelectSaver, Dumpvalue, Selfloader, even CGI.pm. And now, due to backwards compatibility concerns, we're stuck with them. Since its less work to just continue shipping them then to remove them, there they remain.

Now consider putting XML modules into the core because people find them useful. But a lot of people don't. And at some point in the future few people will find them useful. And then we'll be pointing at XML::Parser in the core and saying "god, look at this bloat!"

And then what happens when XML::Parser::Of::The::Week we include in the core goes out of vogue and everyone is using XML::Fancy::Parser? The prime example of this is CGI.pm. Years ago CGI.pm was the best thing out there for CGI (and many thanks to Lincoln Stein for that) but now there's much better CGI solutions on CPAN. CGI.pm gets an artificial boost to its popularity due to the perception that it is the "official" CGI module and its elevated position of convenience because it comes installed with perl. All other CGI modules have to work twice as hard to be noticed because of this.

Some people like XML. Great. I have little use for XML but I do a lot of work with databases. Should DBI go into the core? What about DBD drivers? Which one? DBD::mysql? DBD::Pg? DBD::SQLite? And how about GUI programming? We should ship with WxPerl! But what about QT? And for the web folks, WWW::Mechanize and Template Toolkit. Oh, but if we include TT we have to include Mason because we don't want to bless "one true templating library"...

I trust you see the problem with putting "useful" modules into the core. Everyone's idea of what is useful is different and over time what is useful will change until all those useful modules are nothing but dead weight.

This is why there are three reasons to add a module into the core: 1) It helps build Perl itself. 2) It helps install more modules. 3) It's a dependency of 1 or 2.

ExtUtils::MakeMaker is an example of #1. Archive::Tar and CPANPLUS are examples of #2. Module::CoreList is an example of #3.

But a bad solution does not mean there's not a problem. It needs to be easier to get the necessary tools for your programming niche. PHP solves this problem by bundling everything into the core, and even though the solution is awful it is a solution and PHP is easier to use than Perl "out of the box".

It would be great if there was *another* source distribution of Perl that had LWP in it. Or Wx. Or DBI and a pile of DBD modules. Or XML stuff.

Go make one.

Seriously. Perl is Open Source. Grab the 5.8.8 source distribution, grab whatever CPAN modules you like. Put them into the ext/ source directory. Release. Talk to p5p and maybe you can get it "blessed".

You don't even need to do that much. Just make a list. A list of what is considered the best modules for an XML developer out there. Or a database developer. Or a sysadmin. Or an ISP. Or "best practices". Publish these lists and then distributors of Perl, like Redhat and Debian, can know what modules to package.

Lots of people complain about this problem, I must have heard it from a half-dozen people at YAPC. Now you know a solution. Implement it.


SDKs

barbie on 2007-07-02T08:30:38

This is similar to the SDK idea I posted some time ago. I still haven't had time to take that particular idea further, but creating an SDK to handle a known Database install, or Templating install or whatever, would seem a better idea than bundling them into a single core distribution.

Re:SDKs

davorg on 2007-07-02T14:34:10

This is the same SDK idea that has been knocking around since... well, certainly since I first went to a Perl conference in (I think) 2000 :-)

So what would be the point?

sigzero on 2007-07-02T12:18:43

I don't like the idea either. Maybe a re-think of "core" should happen. I typically install Perl and then I have a list of standard modules that I use and they get installed via CPAN. Everyone and their mother is going to have a different list of what they consider useful. Keep the install as lean as possible. If I want something, I will get it.

Add-on packages

bart on 2007-07-02T14:17:01

I don't like the idea of alternative Perl cores. I'd prefer add-on packages, which would be like bundles, except they'd include everything and the kitchen sink, for specific distros. They'd include everything but the core perl distro.

It would be a bit like PPM distributions for ActivePerl, or APTGET packages for some distros of Linux.

The good thing is that there is no clash if you want the module bundles of two different "cores". You ought to be able to just install both, without installing Perl twice.

There's a bit of a problem using CPAN to build some bundles, but it gets a lot worse if it needs external libraries. DBD::SQLite has the right idea: it includes the library. That makes life a lot easier for people trying to install it. Of course, there's the little matter of the license for the library... And so it begins.

People should not have to be computer geeks just to build a usable Perl setup.