3 ms·
I really don't understand where this oft-repeated FUD about Moose having a lot of deps comes from. Take a look at the list of deps on https://metacpan.org/relea
by autarch 14y ago
I really don't understand where this oft-repeated FUD about Moose having a lot of deps comes from. Take a look at the list of deps on https://metacpan.org/release/Moose https://metacpan.org/release/Moose
I count 18 direct dependencies, 2 of which are core. If you look at the full expanded deps list at http://deps.cpantesters.org/?module=Moose http://deps.cpantesters.org/?module=Moose it's not many more, especially since most of the 2nd (or more) order deps are core modules like ExtUtils::MakeMaker, Test::More, etc.
For extra added irony, a bunch of the Moose deps are tiny modules we extracted from Moose or Class::MOP in order to make their functionality availability _without having to install Moose_. This includes Class::Load(::XS), Package::Stash(::XS), Devel::GlobalDestruction, Package::DeprecationManager, Eval::Closure, and Dist::CheckConflicts.
Had we just note bothered to break things up we'd have to deal with a lot less complaining.
- mhd 14y ago18 isn't "lots"? I'm not saying that I've got a problem with this, as installing CPAN modules and deploying them isn't really a problem at all. I think in the end it's probably the wrong decision to avoid using features just because of something easily automated. I just meant that I can understand the desire. We programmers try to make code clear and concise (hopefully), so that we can better keep the system in our heads. Apply this on a larger scale, and you often get reinvented wheels and proprietary solutions. "Other people's code" is often used as a curse. Hey, my day job involves Catalyst and Moose heavily, and I wouldn't ever want to go back to enterprise Java. So if I came of as "fuddy", I'm sorry.