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.
I missed the part about collections. See below.
> 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.
It looks like maybe we could use 'virtual' packages like I mentioned below to solve this:
YAML:
requires:
[db_driver]: postgresql || mysql
[postgresql]:
DBD::Pg: > 0
DataTime::Format::Pg: > 0
[mysql]:
DBD::mysql: > 0
DataTime::Format::mysql: > 0Square brackets denote virtual packages or macros. This should solve all the issues you mention as far as YAML goes. The Build.PL file is much more flexible; we can express these dependencies in many ways. There is not much of an issue there.
I guess one other thing that needs to be considered is: allowing other modules to make use of this. I think one of the things we wanted to allow is for the actual package being installed to access some of the same functionality in order to allow/disallow some functionality. For example, some modules will run in an enhanced mode if a module is present. It would be nice if we could provide this type of dependency checking in a central place. I believe that this is where a module like CPAN::Metadata comes in, but I think Ken had some other ideas. But a more complex specification like above certainly seems to argue for providing an interface for determining whether those dependencies are satisfied.
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
