I'd be really happy if the ideas expressed there started to get in shape and implemented. Especially I'd be glad to have various stable snapshots of CPAN based on perl version or operating system or both.
On one hand I usually recommend using CPAN modules instead of writing your own code but probably every one of us has a limit of minimum code avoided by using a dependency. Just to pick one of my favorites, using File::Slurp is probably plain bloat as writing that 4 lines of code that can read a file in slurp mode and putting it in a function is probably a lot cheaper than installing File::Slurp.
Of course File::Slurp has some other tools as well, e.g. write_file so when you start implementing those you will start to feel sorry that you have not used File::Slurp in the first place. This is one of the reasons people implement stuff on their own. First they only need a small subset of what a module provides so they don't feel it justified to include the whole apparently to them - bloated module. Then throughout the life of the product they need to add more and more features that could be found in the other module so they expand their own implementation. They usually can't switch to the CPAN module either because the API is different or just for political reason. What? Are you planning to throw away all that code you wrote?
If some of the deeper dependencies of my code already uses File::Slurp then I (or the user) already has to pay the installation price so I could just as well use that code.
For that it would be nice to be able to check the list of all the dependencies of a CPAN module has every time I am planning to use it. CPAN Dependencies is a nice tool for that though I think it does not support optional dependencies and it certainly won't support modules and applications not on CPAN. That would be a nice extension though to support DarkPAN.
Published on 2009-05-09 by Gabor Szabo