On Jul 18, 2004, at 10:08 AM, David Wheeler wrote:
On Jul 17, 2004, at 8:57 PM, David Wheeler wrote:
Agreed. I'm racking my brains (and the brains of those around me), but I'm not coming up with anything. I like finding the right language for things, though, so I'll have to think about it...
Hrm, I kind of like Smylers' suggested term, "abstract". Maybe abstract_requires in Module::Build?
Sorry I haven't had a lot of time to chime in - we had the baby niece & nephew over the weekend.
Unfortunately "abstract" is already taken in the META.yml: it's a short descriptive phrase of the module.
Regarding the concept-formerly-known-as "virtual packages", I think I'd like them to tie into the "features" concept more. I think perhaps it's time to write that boolean requirement specification stuff, and then we can use that both in the "normal" requirement specs and the requirement specs for a declared feature.
The idea would look something like this:
-------- in the Build.PL ------------------
features => {
# Old-style requirement spec
'yaml_support' => {
description => "Can read & write YAML files",
requires => { 'YAML' => 0.13 },
recommends => { 'YAML' => 0.49 },
},
# New-style requirement mini-language spec
'dbi_support' => {
description => "Can read & write databases",
requires => q{
DBI >= 1.0 ,
(DBD::mysql >= 1.5 || DBD::Postgres)
},
},
This method will require a complete expression parser, which is admittably easy to implement. It just seems a little more error prone. Also, expressions can be arbitrarily complex which can make it more difficult to write expressions in a human readable format (David's example hints at that complexity). That's why I liked extending the existing format: less parsing for humans and machines.
features => { ... dbi_support => { description => "Can read & write databases", requires => { DBI >= 1.0, db_driver => q{ [mysql] || [pg] }, [mysql] => { DBD::mysql => 1.5, DataTime::Format::mysql => 0 }, [pg] => { DBD::Pg => 0, DataTime::Format::Pg => 0 }, }, },
This way most of the parsing is already done; Most all the terms are already broken down into indivisible fields. It's more human readable (IMO), though, perhaps a little more verbose. The macros help diffuse the complexity of expressions.
Randy.