P is for Practical | |
PerlMonks |
Re: Which version to target for module dependencies?by jkeenan1 (Deacon) |
on Aug 18, 2005 at 14:11 UTC ( [id://484785]=note: print w/replies, xml ) | Need Help?? |
In general I agree with tlm that the answer lies somewhere between 3 and 4. But I also think you're on to something when you suggest different approaches to core and non-core modules. So at the risk of suggesting an approach #5 ...
With core modules I ask: "What version of Perl am I requiring? Was the module I'm listing as a dependency distributed with Perl in that version? And, if so, did it lack any features at the time it was introduced to core that I now want?" If the answer to the that last question is yes, then I have to go to that module's Changes file, see when the desired feature was introduced, and explicitly list that in Makefile.PL. If the answer is no, then a simple require [targeted perl version] takes care of the problem. The answer to the second problem can be approached with Rafaël Garcia-Suarez's Module-CoreList. The answer to the first problem is to ask, "How backwardly compatible do I want my module to be?" If the code is going up on CPAN for universal use, then you may want considerable backwards compatibility. OTOH, if you're a consultant designing an application for a customer, you can be much more flexible depending on his/her upgradeability potential. With respect to non-core modules as dependencies, it's much more of a crapshoot. Approach #3 seems very reasonable there. Let CPAN users give you feedback if you're requiring too recent a version, then change it in your next upgrade. (I personally shy away from distributions that sit on a mountain of dependencies, but that's more of a personal taste.) And, of course, given the distributions you listed as examples, one should ask, "Do I need this module for my module's functionality, or simply to write a better test suite?" But that is for another thread (and has been!). HTH Jim Keenan
In Section
Seekers of Perl Wisdom
|
|