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)
},
},
In other words, when the value of "requires" or one of the other dependency items has a string value instead of a hash value, it means that we're using the mini-language to express those dependencies. It can also be used at the top level of the distribution, not associated with any sub-feature.
Then, if we need macros (which is I think probably a better term than "virtual packages") we can add them in, but I think we can probably get by for a long time (perhaps eternally) without them.
-Ken
