On 07/09/2007, Zefram <[EMAIL PROTECTED]> wrote: > > Adam Kennedy wrote: > >Modules don't declare dependencies on distributions, and never have. > > True. But it's distributions that have the optional_features. > > >They declare dependencies on APIs, described as namespace/version pairs. > > So to fit in with this system, we could arrange for each optional feature > of a distribution to be reified as a module.
Ignoring your specific case, the answer is yes. Anything that has optional elements where those optional elements can be expressed as a namespace and version pair can be made to work with the CPAN process. For a precedent of this type, take a look at the Task:: namespace we created a few years ago. The (only?) downside is having an extra, small, > distribution on CPAN for each optional feature. That's totally fine. The extra distribution is serving a useful purpose, which is to verify that some functionality (and thus, that part of the API) is installed and working. If it fails to install, then it fails for the right reasons, in the right place, and likely with the right type of error mesages. The specifics of your solution seem, at least on a quick initial read, quite workable. > (because configure_requires isn't quite ready for > >prime time yet). > > I think you're referring here to something else I was wondering about > dependencies. build_requires declares things that are required at the > time of running ./Build; is there any way to declare things that must > be installed before running ./Build.PL? Is that what configure_requires > is for? Correct. It resolves the problem of a turing-complete dependency reporting process being unable to calculate the dependencies required to execute the calculation. I have a module, Time::UTC::Now, that needs to experimentally compile > some C code in order to determine which interfaces are available for the > main XS code to use. Currently it does this probing in Makefile.PL. > Translating into Module::Build, I'd need ExtUtils::CBuilder present > before Build.PL could run successfully. > > Incidentally, on reflection I think the `optional features' of > my numeric modules are actually best handled as a "conflicts". > That is, Date::ISO8601 does not really depend on Math::BigInt>=1.64 > (as it currently declares), but it conflicts with Math::BigInt<1.64. > META.yml solves a problem for me there. One interesting method for that situation may be to look for the existance of Math::BigInt. If Math::BigInt is installed, report a dependency of Math::BigInt 1.64. If Math::BigInt is NOT installed, report no dependency. In this case, if it is installed in future it should (in almost all scenarios) be the newest version, which also will be fine. I noticed a problem in the definition of the "conflicts" section of > META.yml. Hypothetically, suppose that my Date::ISO8601 module could > work with any Math::BigInt from 1.64 on *except* for 1.70. In reality > there is no such exception, but the version syntax of META.yml allows > for such, because I can declare the positive dependency thus: I should note that META.yml is aspirational, not all of it's elements are supported by the CPAN as a whole. I'm not aware of any active uses of conflicts. Adam K
