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