Re: [Module::Build] Re: Opting out of rt.cpan.org

Ken Williams wrote:
> 
> On Mar 6, 2006, at 4:44 PM, Randy W. Sims wrote:
>> There are a number of problems it could be intended to solve, but  I'm 
>> not sure which one(s).
>>
>> 1) For automated builders/testers, it could indicate that a module  
>> requires user intervention. Eg. it queries the user for input  during 
>> install.
>>
>> 2) The dependencies listed in META.yml are not static. Maybe a  
>> Win32::* module is required only when run under Windows, but is not  
>> listed in META.yml because there is currently no way to express  
>> conditional dependencies.
>>
>> 3) The description in the spec would seem to imply that a static  
>> config indicates that module can be installed without the builder  
>> (i.e. Module::Build)), that the modules could simply be copied into  
>> the proper folders by any tool. This would mean any module with  with 
>> XS or compiled code as well as anything under (1) and (2)  above are 
>> dynamic?
> 
> 
> I'd intended it as 1 & 2 but not 3.  In other words, whether the  
> information in the META.yml is definitive or not.  If it weren't,  then 
> a cautious or curious user might want to read the Build.PL  before 
> installing.
> 
> Everything is on the honor system of course, so it's not really a  
> security thing, just a convenience thing.

Maybe that section could be clarified a bit:

:>>>
(Spec 1.0) [optional] {boolean} A boolean flag indicating that the 
content of the META.yml does *not* represent a complete and static 
description of the distribution. If the properties of the distribution 
as described by META.yml change depending on operating environment or 
user choice, this should be set to 1 (true).

For example, if one of the prerequisites this distribution 'requires' is 
only needed on BSD flavored platforms, the metadata would be considered 
"dynamic", so the 'dynamic_config' field should be set to 1 (true).

If this field is omitted, it defaults to 1 (true).
:<<<

The above with other clarifications and corrections you've made could 
maybe be a 1.2.1 release maybe?

And/Or with the following a 1.3 release:

The alternative listed under "recommends" should probably be removed or 
made an official part of the spec.

The repository field could be constructed as a mapping:

   repository:
     type: cvs
     location: :pserver:[email protected]:/cvsroot/module-build

or possibly some type of (icky) compound field:

   repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata

Randy.