Ken Williams wrote:
I freely admit that I haven't been following this thread closely (I guess Ken's posts have a lower activation energy for me), but the suggested approach sounds way overengineered. How many modules really needs this kind of thing? I'm not sure that adding complexity to the requirements management system for those learning/using Module::Build is worth it for what I imagine to be relatively few modules that would wind up using such functionality.
On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote:
On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote:
Should we completely open this up so that requires/recommends/conflicts can be applied to any action?
install_recommends => ... testcover_requires => ... etc.
This sounds useful and solves a lot of problems at one sweep. You can use
the existing dependency architecture to determine what needs what. Such as
testcover needs both test_requires and testcover_requires.
There's a problem with this that I'm not sure how to solve: what happens when, as part of refactoring, a chunk of one action gets factored out to become its own sub-action? The dependency may well pertain to the new sub-action instead of the original action, but distribution authors won't have any way to know this - or even if they did, they couldn't declare it in a forward-compatible way.
I'd rather see requires/recommends kept at a high level and let individual actions/tests check for what they need and be smart about how to handle missing dependencies.
Regards, David
