Re: [Module::Build] requires_one_of

[David Wheeler]

Moving the conversation over to module-authors...

On Jul 16, 2004, at 11:52 AM, Randy W. Sims wrote:

David Wheeler wrote:

On Jul 9, 2004, at 3:00 PM, David Wheeler wrote:

Yes, but what about applications that require one among a list of modules? I'm thinking of things like DBIx::SearchBuilder, which requires one of several DBDs, and various XML modules, which require one among a list of parsers. In a case such as that, I don't know what to do about META.yml.

Maybe there should be a way to specify that there is a requirement for one among a list of modules? Or even that there one of several groups of modules is required? Something like this:

    requires_one_of {
        dbd => {
            DBD::Pg => {
                DBD::Pg => 0,
                DateTime::Format::Pg => 0,
            },
            DBD::mysql => {
                DBD::mysql => 0,
                DateTime::Format::mysql => 0
            }
        },
        parser => {
            XML::Parser => 0,
            XML::LibXML => 0,
        }
    }

Here either XML::Parser or XML::LibXML is required, and either DBD::Pg and DateTime::Format::Pg or DBD::mysql and DateTime::Format::mysql. These could also be represented in YML, of course.

Should I resend this proposal to the module authors list?

I think one of Ken's original ideas (and one that I like really like) is to provide a flexible language for describing dependencies, including situations like you describe above. IIRC, the idea was to provide a way of saying things like:

DBD::Pg > 0 || DBD::mysql > 0

That's not bad, although it doesn't help to specify collections of related modules like my proposal does. Also, AFAIK, the current Module::Build syntax for version number requirements doesn't support this, and isn't likely too, it seems to me, since module names are not included in the version spec string. They're only the hash keys.

Debian's package manager does something different. A package can belong to a 'virtual package'. For example there is a virtual package for email-client. Any package that belongs to the virtual package email-client would satisfy the dependency of another package that depends on the that virtual package.

Hrm. That's not a bad idea. Not sure how that'd work with CPAN, though. Bundles are the closest thing, and even with the successful installation of a bundle doesn't mean that all of the modules it includes have been successfully installed.

While I like debian's approach, I'm not sure it can easily be retrofitted onto the current system. One way in which it might be possible is to introduce macros such that you can define 'virtual packages' in the META.yml file and the packages that satisfy it. Then use that macro in the requirements. Of course, the thing that makes Debians system nice is that you do not have to change the package that has a requirement on a virtual package when a new package that also fits the requirement is introduced. But that would require a database of all CPAN modules.

Yes, which there is, in the module list, but it's pretty limited at this point. I kind of like this idea, too, but I'm not sure how well it will work. The advantage to my proposal, on the other hand, is that it's fully self-contained in the META.yml.

module-authors might be able to come up with some other alternatives.

Moved there now. Thanks for the feedback.

Regards,

David

smime.p7s
Description: S/MIME cryptographic signature