The first answer is Perl 6 - it will come with a strong object system in which much can be declared, so I guess it'll make most (or all) of Moose and MooseX::Declare superfluous.

But I agree that Perl distributions are a good idea. Actually ActiveState ships with more than just the core modules by default, and I wouldn't be surprised if Strawberry did as well. Many Linux distributions already have native packages for many CPAN modules (for example Debian has packages for Moose, named libmoose-perl). So it's already happening in some sense.

Putting more modules into the Perl core is to be avoided, and neither the Moose folks nor p5p really want it.

Actually Mouse should really only be used in cases when it is a hard requirement to use less memory/cpu/dependencies. We are trying to actively discourage people from using it for convenience sake, since we hope by the end of this year to have completely removed the need for it to exist at all.

-stvn

we hope by the end of this year to have completely removed the need for it to exist at all.

Can you elaborate on what need you see for it to exist and how you aim to remove it? Depending on how you define the terms, this statement could mean anything from "we're working to improve Moose's speed" to "Moose is replacing blessed hashes in /usr/bin/perl".

I won't speak to the performance issue, but you could cut down the dependency insanity by not requiring Test::Exception. Is your Test Flavor of the Day worth 17 dependencies?

I also have a hard time choking down some of the dependency lists for things I like but many CPAN authors have been taking a lot of responsibility for making sure their code passes tests and won't jam up a long list of stuff. I'm really impressed with it. Ultimately, it also seems exactly the right course. Should Catalyst, for example, duplicate the snippets it uses from 50 other modules just to have a self-contained release? No, (exact) duplication is a great evil in this stuff. It should be in its place with its changes, bugs, expert owners, etc.

On the Linux dist front; they are very convenient but I have seen them used repeatedly at $work as an excuse to not fix bugs and do without features for a year or more after they become available. I know tracking builds and installations ad hoc is difficult but I really dislike the way dists play out in the real world. They move the burden from the sysadmin to the hacker. And maybe that right there sums up why I'd keep CPAN/Perl chugging along as it is. It only seems to be improving and it's driven by peers, not anyone up or down the chain.

In principle, I agree that exact duplication is to be avoided.

In practice, I don't do Catalyst because I refuse to install half of CPAN just to get it running, particularly given that, when you have over 200 dependencies¹ involved, the odds are pretty high that the majority of them will not be actively used by any given Catalyst app. There are limits to how far you should bend over backwards in your attempts to avoid duplication.

 

¹ "Catalyst now depends on Moose among other things, with a very long overall dependency change[sic]. How long? I downloaded Catalyst 5.8 along with all of it’s non-core Perl module dependencies. The result was over 250 modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh."
- http://mark.stosberg.com/blog/2008/11/review-of-mojo-087-a-new-perl-web-framework.html

Yeah, I don't enjoy the long lists either and I think it could be pared down but I have Cat running just fine on a budget host and in three different other environments under the test server, fastcgi, and modperl with very little effort so whatever critique or displeasure is involved is not actually in the way of using it. The Cat devs shouldn't be responsible for maintaining things like Set::Object or Data::Visitor and too often I see folks at work using the anti-dependency shtick as an excuse to put snippets from the Cookbook everywhere.

Just last week our manager insisted we use the &commify recipe we all know and love instead of Number::Format or something. This was one week after we were asked for an estimate of how long it would take to i18n our main app because we have some interest from a foreign buyer. So, we just put one more hurdle in the way of ever being able to manage that; commas v points in numbers based on locale. We chose to hardcode US-ish behavior based on fear of a single dependency.

Duplication isn't just wrong because of code drift, it's also wrong because it's a certainty in a big app that someone else has solved that part of the problem better than you can or that they will improve the solution over time in their code base.

200 dependencies is scary but you can view it as something like 10,000-50,000 free hours of development instead. :)

Well, keep in mind that Moose is different from MooseX::Declare. The later has a much longer dependency chain because honestly it is doing a lot more (parsing signatures, fiddling with op-trees, wrapping methods, etc). This is quite different from the core Moose dependency chain, which is fairly short for what it provides.

Now, I have personally run into occasions where a Moose install was pretty hefty, but in those cases it was usually because some of the core modules I had were old. If I recall correctly it was the Test:: modules that were out of date and that did result in a seemingly long dependency chain.

Is it time to start treating Perl like linux and have *distributions* that package what we need? A Sysad distro? A Web App distro? A Modern Perl distro? I don't have an answer ... just curious.

One of the eventual goals of the Enlightened Perl Organization is to eventually have an "enlightened perl" distro that will include all these things already. I am not sure where this project is currently at, but if you are interested in helping you should shoot them an email.

The status of the EPO Group working on that project is probably easiest to find on teh EPO wiki

Moose's dependencies according to cpantesters is 24 modules including 4 core modules under 5.8x. This number drops under 5.10x because more of them are folded into core.