David -- I think you're misunderstanding the proposal -- or rather, two proposals.
(a) Have M::B or EU::MM/M::I create MYMETA.yml at the end of running Build.PL or Makefile.PL -- this isn't an *author* issue, this is something that happens on end-user machines. If that file is created, then other toolchain modules or QA modules will use it. They'll still be backwards compatible, of course. For example, I've already created a CPAN.pm branch that supports it. This will use the exact same spec (except for dynamic_config) as META.yml and of course, has all the same YAML issues. But since the same tools that generate META.yml today will generate MYMETA.yml, we're not better or worse off than we were before. (b) Adding 'maybe_requires' (or 'dynamic_requires' or whatever an intuitive name is) to the META.yml spec and upgrading M::B and EU::MM/M::I to support it. This does effect authors if they want to change to support it, but since it's only adding granularity of meta information, not new information, it's still backwards compatible. Does that clarify? David On Mon, Feb 2, 2009 at 12:23 PM, David E. Wheeler <[email protected]>wrote: > On Jan 29, 2009, at 3:47 PM, David Golden wrote: > > (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 can be handled by adding an optional dependencies parameter to > Module::Build and EU::MakeMaker. TO me, this is not a problem solvable by a > metadata file and not by the current build script system. > > (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. >> > > Right, but I'm not clear on why we should impose yet another approach to > building modules on all CPAN authors just to make things easier for "the QA > ecosystem," which generally ends up running the tests for the modules, > anyway. > > 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. >> > > Yes, but we could add such a way to the existing META.yml spec, no? > > 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. >> > > Who will be generating this MYMETA.yml? How many of them will there be, one > for each system? That's a lot of files! > > (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. >> > > Oh, without question. But again, I don't see how another metadata file > solves that problem. At least, not any better than a build script does. > > 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. >> > > Well, the problem with that is that YAML is a finicky bitch. You'll end up > with a lot of broken MYMETA.yml files on CPAN (or, more likely, very few, as > authors won't have the patience to create them) if they have to be created > by hand. Better would be to add the functionality you need to Module::Build, > and then have it generate such a file (or just add the info to META.yml; I'm > still not understanding why yet another metadata file is required). > > Best, > > David > >
