Re: META.yml feature for autotesters?

[email protected] (Adam Kennedy)
Newsgroups perl.qa,perl.cpan.discuss
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.