On Thu, Jan 29, 2009 at 5:55 PM, David E. Wheeler <da...@kineticode.com>wrote:
> So what I'm asking is (and if I missed some other conversation about this, > apoligies!), what's the point of this? What problem are we trying to solve? > I'll try to summarize what I see as the issues -- though I'm sure people will have TIMTOWTDI workarounds for each, I'm pretty sure the core issues remain. (1) Optional dependencies (2) Conditional dependencies (3) Communicating dependencies I'll comment on each one. (1) Optional dependencies: Some modules perform "better" with optional modules. This "problem" tends to be solved by having Makefile.PL/Build.PL prompt users whether they want certain extra modules installed, which has the downside that users can't easily set a default policy in their installer tools short of accepting *all* prompt() or autoinstall defaults, which is not necessarily ideal either. Finding a way to communicate to the installer tool that some modules need the user to decide about installation would allow such decisions to be handled by the installer, not the configuration file. This is mostly a communication issue -- so see item (3). There is a related issue of whether "recommended" modules should generally be installed, based on differences from the Debian semantics about "recommended". (2) Conditional dependencies: Parts of the QA ecosystem gather information about dependencies. These are not necessarily installing modules and they are often covering all of CPAN, so there is a desire to gather dependency information without running code. This is problematic for general conditional dependencies unless the configuration language becomes a complex DSL. The META.yml spec does not include a way to specify conditional dependencies. Instead, whatever dependencies are conditionally determined to be needed for the author's system are what get put into META.yml's ordinary 'requires', 'build_requires' and so on. MYMETA.yml has been proposed as an alternative approach to the problem of collecting conditional dependencies -- rather than try to make the META.yml contain conditional logic, MYMETA.yml will contain the *result* of conditional logic for a particular system and that post-configuration output can be collected and used to impute conditional dependencies. (3) Passing all prerequisites as PREREQ_PM out of the Makefile is a clumsy way for an installer to learn about dependencies that must be installed. Nor does it provide granularity for identifying modules that are needed to build/test but should not be installed or for optional dependencies such as in (1) above. There doesn't seem to be a lot of desire to hack EU::MM to stuff more information into Makefile. Instead, the idea is to use META.yml -- or, soon, MYMETA.yml -- to communicate dependency needs back to installer using a well-defined data structure. Because MYMETA.yml is a post-configuration result, concerns about META.yml defaulting to "dynamic_config: 1" are avoided. -- David
