If you want something to work on, I'd love to give you either PDF::Template and/or Excel::Template. Or, I could use help working on DBM::Deep on Win32. Or, any of the other 20 really cool module ideas I have rattling around that I simply don't have time to work on. Like Presto. Or PerlGems.

You did note the "small benefit" part? I am not arguing for dependency-free modules, but for as little dependencies as possible, which of course is no absolute, but something worth thinking of; and "as possible" has many constraints.

So, I go ahead and put in a dep on ABC because it saves me half the project. It has a dep on DEF cause that saves it half the project. DEF's author is stupid and has 30 deps. Should I avoid ABC because of that?

DEF's author is stupid and has 30 deps. Should I avoid ABC because of that?

I'd say yes, definitely - if you can afford it. Otherwise the submit to CPAN is questionable. ABC is likely to break (weakest link chain rule) because of DEF. Don't avoid ABC if you can convince its author to not use DEF, or if you can convince the author of DEF of the "less is more" principle. It is your module that's beholden (?) as unusable - even if the fault lies in DEF.

update: I'm checking your modules =~ /${'my aptitude'}/

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

because there are problems with module dependencies; dragonchild has named one - lack of standards - and pointed out the benefit that drawback brings.

Yes, I agree with dragonchild on that, however TIMTOWTDI is core to the Perl Way of Life and standards are counter to that. Of course TIMTOWTDI is a double edged sword here especially.

You did note the "small benefit" part? I am not arguing for dependency-free modules, but for as little dependencies as possible, which of course is no absolute, but something worth thinking of; and "as possible" has many constraints.

I will say, and I suspect you will agree, that choosing to add dependencies is something that should not be taken lightly. For instance, if the module looks abandoned I will sometimes opt to write it myself because I don't want to depend on something which is unmaintained and might break and mess up my module with it. But a good solid module (like Class::Accessor) can be depended and it used widely enough that I would not even think twice about using it, knowing full well that many people will probably already have it installed.

One of the really great things about Perl is CPAN, and one of the really great things about CPAN (IMO at least) is how much interdependency there is in it. If you take a look at the state of Python, Ruby or even Java modules you will find many more monolithic codebases (although ruby and python are getting better now last I checked). I would submit that this is directly related to the level of tool support to automatically resolve dependencies such as CPAN has. Anyway, just my 2 cents :)

I will say, and I suspect you will agree, that choosing to add dependencies is something that should not be taken lightly.

That looks like you understood my rant ;-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

That looks like you understood my rant ;-)

Yes, I knew where you were coming from. I too have been up until 2am fighting a broken dependency chain on 3 different prod servers that were supposed to be back online hours before, so I know the pain you speak of. But in the end we just didn't come to the same conclusions.

-stvn