One of the nice features of Perl is the enormous number of extension one can get from CPAN. It is also one the problems. If an application relays on several CPAN modules it needs to either include them in its own distribution
or the user/system administrator will have to install the modules using CPAN.pm or some other method. While there is a huge improvement in the ease of installation of modules using CPAN.pm, it is still a problem.
Especially on shared web hosting system
I think it would be nice if on standard systems the installed Perl module would cover more areas.
According to this talk of Nick, Perl 5.10 will no longer be "one size fits all". There are plans to have various size dists.
On the other hand in
this thread of the perl5-porters about the roadmap for 5.10, while Hugo seem to be in favour
incorporating Module::Build, CPANPLUS and Inline or a minimal subset of it, I have not seen the issue of various sized dists come up. Have they maybe dropped the idea ?
From various other threads here and
here
I conclude that I might not be the only one who thinks having more CPAN modules in the core might make Perl more attractive to the developers. It will be easier to distribute software if all their prerequisites are already
installed.
On the other hand for any software eventually you will need to get additional modules or newer version of existing modules so maybe having a much larger number of CPAN
modules installed on a system won't solve the problem.
So I am wondering what do you monks think about this ?
Would such a large Perl installation solve any problem or would it make worse ?
Which modules would you include in such a distribution ?
Let me put here my short list
- Module::Build, CPANLUS - but these two will likely get in 5.10 anyway
- Test::* a number of test related modules
- DBI
- DBD::SQLite
- Class::DBI - and its Plugins
- CGI::Appliation and its Plugins
- Kwiki with its horde of Plugins
- Some XML related tools (e.g. XML::Simple)
- Modules listed in the
Phalanx 100 that don't have too many external dependencies (e.g DBD::Oracle will need to be left out I guess)
So what do you think ?
|
Re: Larger Perl distributions
by Thilosophy (Curate) on Dec 26, 2004 at 03:37 UTC
|
I agree it is a problem to get applications working that require a lot of non-core-distribution modules. But I do not think packing everything into the Perl distribution is a good idea. I am also not sure anymore if installing application-specific modules into the standard site_perl directories is always good, either. If you have many applications running on the same system, you sometimes want incompatible versions of the same CPAN module, for example.
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. | [reply] |
Re: Larger Perl distributions
by Juerd (Abbot) on Dec 26, 2004 at 21:16 UTC
|
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.
| [reply] |
Re: Larger Perl distributions
by zentara (Archbishop) on Dec 26, 2004 at 11:27 UTC
|
Dosn't CPAN already have the "bundle" concept going? Why not make a set of bundles, that users can download separately and unpack before they build Perl? Like bundle-audio, bundle-dbi, bundle-net, bundle-crypto, bundle-tk, bundle-gtk, etc.The bundles could even include any necessary c libraries needed by the modules, so it would be
a 1 step build and install.
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
|
|
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.
| [reply] |
Re: Larger Perl distributions
by jonadab (Parson) on Dec 26, 2004 at 17:52 UTC
|
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.
| [reply] |
Re: Larger Perl distributions
by dragonchild (Archbishop) on Dec 27, 2004 at 14:18 UTC
|
If you're worried about distributing software, look at PAR. If you're worried about shared-hosting environments, look at doing personal installations with perl Makefile.PL PREFIX=~.
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 ...
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.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply] |
Re: Larger Perl distributions
by Anonymous Monk on Dec 28, 2004 at 12:31 UTC
|
One of the drawbacks, and IMO, a very, very big drawback is that for any module included in the Perl core distribution, the burden of maintainance ultimately falls on p5p. It's not so much a problem if the maintainer is active, but it is when the maintainer has fallen from the planet. Or just doesn't fix it. A lot of effort of p5p goes into trying to archieve backwards compatability - and one obvious consequence is that it's very, very hard for a module to disappear from the core. Just witness chat2.pl - the module that didn't want to die.
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).
But no CGI, no Benchmark, no Memoize, no Switch, no Text::*, etc.
(Note, I'm not saying they should be removed. They just shouldn't have been there, IMO). | [reply] |
Re: Larger Perl distributions
by Jaap (Curate) on Dec 26, 2004 at 11:35 UTC
|
| [reply] |
Re: Larger Perl distributions
by redlemon (Hermit) on Dec 27, 2004 at 12:42 UTC
|
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.
| [reply] |
|
|
