develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.

From:
Johan Vromans
Date:
June 20, 2006 03:38
Subject:
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunk our own self-generated FUD.
Message ID:
m23be03ye7.fsf@phoenix.squirrel.nl
demerphq <demerphq@gmail.com> writes:

> Also moving more commonly used modules into core perl, making the core
> perl experience more usable would improve the lot of many, many, many
> a perl developer who is limited by policy that they cannot form
> dependencies on modules that arent in core. A group that I think is
> much larger and IMO much more important than the "minimal core" types
> realize.

What some people consider critical core functionality is considered
unnecessary bloat by others. There's no easy way to solve this. A
thourough investigation would probably reveal that some 30% of the
current core modules are hardly used, while 100s of popular CPAN
modules would be considered desired core functionality. It would be
possible to improve the current situation, but in the end it will only
pospone the threshold.

In my opinion, a more intelligent installer that could solve
dependencies more transparently and reliably would be a better
approach. ActiveState's PPM already does a fairly good job at this.
However, still my opinion, this would also require the possibility to
store application modules in a different location than under the Perl
tree. Storing modules under the Perl tree is okay for general purpose
library modules, but plain wrong for application private modules.
Applications that require specific additional (CPAN) modules could
then install these in this private area as well, without possible
conflicts with other applications. This would also make it possible to
ship a specific version of a CPAN module with an application, if the
application requires this specific version of the module to work with
(yes, this happens).

Complicating factor is that specific operating platforms have a
different idea of what that "private area" should be, making a
platform neutral installer an (almost?) impossible task.

"perl Build.PL; Build test; Build install" will always be an option
for the knowing application installer. Joe Average User will want to
use his platform installer.

-- Johan




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About