I think large Perl applications should include all their dependencies in their own library path, and small applications should get their modules from a user_perl path. In both cases, you do not need superuser rights to manage these installations, which is especially good for shared hosting. Both is already possible, even with the CPAN tool, but it could maybe get easier. For example, when a non-root user does CPAN install it could install into a user_perl directory that would also be automatically recognized by the Perl runtime.

Let me put here my short list.

That list would be very different for everyone. If you include Class:DBI, CGI::Application, Kwiki (very application specific stuff) it will make it difficult to argue where to draw the line.

The problem with picking modules for a distribution is that everyone has their own favourite modules (2002, 2003, 2004).

The standard distribution doesn't have a clear module inclusion policy. It has some well written modules, but also some that especially beginners should probably not use. And by saying that, I probably provoke discussion (and hereby immediately undone :)), which says enough about how hard creating a distribution is.

I don't think it's a great idea. But then, I use Debian, and installing and uninstalling modules is even easier that with CPAN.pm's shell, so I'm probably spoiled.

This said, I propose that my DBIx::Simple and xmath's Data::Swap be included. Other modules that deserve inclusion are CGI::Simple and File::Tail. And, as jonadab writes, DateTime.

The bundles could even include any necessary c libraries needed by the modules, so it would be a 1 step build and install.

Most of these bundles already exist. Bundles cannot include anything though. In any case you miss the point since they still have to be downloaded separately, which is exactly what the OP is arguing against.

Makeshifts last the longest.

I seriously don't understand why DateTime has never made it into core; as far as I'm concerned Perl isn't installed until DateTime is installed.

But for a Big Distro of Useful Modules, I would argue for including anything that's ever been written up on the Advent calendar, any year, plus anything that's a dependency for CPAN modules by more than three other authors. (The latter criterion will catch quite a lot of the various Test:: and Net:: modules, plus ones that provide data structures, among other things. The former would catch stuff that's nifty and useful, such as WWW::Mechanize and Data::Dumper::Simple.) Obviously, you'd still exclude anything with outside non-Perl dependencies unless you happened to have those dependencies installed, and you'd exclude any platform-specific modules except on that platform.

The biggest problem I'm seeing is that you're requiring a lot of space just to install Perl. I already get pissed off when installing 5.8.x also installs 2304720387 other modules. Now, these other modules ... I don't use most of them. Frankly, I don't want most of them - if I could uninstall them without breaking anything, I would. Especially on production systems within the DMZ - less security holes. It's not much help, but anything is better than nothing.

Also, Perl is used for more than just web applications. Yet, you seem to want Perl to be web-only. Same with XML.

Personally, I think the core should be just that - the core. Just enough for me to get Perl's interpreter and an easy way to install stuff from CPAN. Maybe a testing module or two. That's it.

Now, if you want to create your own Perl distribution or bundle up your favorite modules ... go right ahead. Nothing's stopping you ...

I think the original idea of having more than one versions of the perl distro meant to have a minimal version as well.

That would probably fit your requirements.

Why not have the core Perl distro be as small as possible and have the DBI bundle and the libnet bundle and the webapps bundle and the ... Oh, yeah ... that already exists!

Why don't people create their own personal bundles? So, if I want an environment just like yours, I can get it because you provide a bundle that has all the modules you have installed?

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I think it would have been better if Perl always had a small module set. IMO, only modules that fall into one of the following classes ought to be in the Perl core:

• Modules that make it easy to install other modules, or that are needed in the make/install process (CPAN/CPANPLUS, MakeMaker, Test::*, etc).
• Modules that are deeply connected to the core. (B::*, IO::*, etc)
• Some pragmas. (strict, warnings).
• Defacto standards (Exporter).

(Note, I'm not saying they should be removed. They just shouldn't have been there, IMO).

There's the additional issue that modules have shorter development cycles than the core language. So e.g. the File::Basename module bundled with the distribution might be updated before the current perl interpreter is.

That means I find myself going to CPAN for most modules anyway, for installation and to find regular updates. So why not take the final step and instead of bundling a lot of modules with perl, change the install process so it initializes the CPAN or CPANPLUS shell and installs bundles directly from CPAN?

Having good quality and topical bundles is a prerequisite in that case, of course. That may be something we need to invest in.