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
