Randy W. Sims wrote:
Adam Kennedy wrote:
To give you some more data points, imagine the automated testing
additions applied only on Win32. How would you then specify the deps?
#187 on the TODO list for M::B is to implement the dEx[1] (Dependency
EXpression) language for inserting complicated requirements in META.yml.
1. <http://svn.versiondude.net/randys/dEx/trunk/lib/dEx.pm>
I'm not completely convinced it's a good idea, but it's one possible way
of handling more complex dependency specifications.
I'm not convinced either.
Just reading through dEx, it seems to be an example of a fairly common
response to being limited only to data expressions.
It seems almost any time someone invents a data format, there's a desire
to have it do more, which leads to the introduction of things that
aren't data.
You start with branch logic, and fairly quickly you need to generalise
that to operators, which requires precedence, and macros/subroutines to
simply and reduce duplication, which means you probably want inclusion
of external files, and then before you know it you have loop logic and
you've just invented a new Turing-complete language.
If we are going to invent a language, I'd much rather just stick to Perl.
So you have a Makefile.PL, it runs on a platform and generates a
META.yml that shows what the dependencies are for that platform.
When you build the package you end up shipping a META.yml that may or
may not be accurate. So while the META.yml can provide a good indication
it will never be able to be 100% useful.
The only exception would be if the META.yml had some form of
"static_config" flag set in it to specifically indicate that the
META.yml is going to be the same everywhere.
Any packaging or automated testing system is going to have to be
required to execute the Makefile.PL, in order to localise the META.yml
for that platform.
That keeps things nice and clear, and means we don't have to create
additional infrastructure to compensate for a lack of sophistication in
the META.yml format.
The alternative leads to things like
<logicml:if condition="foo" expression="foo < 1.0 && eval { require
Foo::Bar; 1; } && bar >= 1.05">
<logicml:for value="bar"...
and so on
If we repair the problem with the dynamic_config flag being backwards, I
think what we have already can be made to work quite nicely (and sanely)
without the need for additional infrastructure.
Adam K
Apart from optional features, which apply across platforms, and across
all installation/testing modes, I think adding more conditional logic
to the META.yml should be considered bad.
I'm on the fence. Ideally, META.yml should be a simple declarative
specification for a module, but with the myriad of runtime environments
that modules (or libraries of any kind) are used in nowadays it seems
necessary. The idea with dEx and its companion CPAN::Metadata is that
they will be the de facto method of reading & writing META.yml, much
like Test::Harness is for TAP.
But that is all theoretical at this point, and subject to much debate
before becoming anything. Specifically, PAUSE/CPAN.pm/CPANPLUS would
have accept it or fall-back on the current method of specification.
Randy.
