Hi Fergal and other, > The difference is that Module::Build forces the Foo::Bar's author to work > out what current versions of Some::Module and Other::Module are suitable and > to try to predict what future version will still be compatible. This is time > consuming and error prone (predicting the future isn't easy) and it has to ...
What I meant is that we shouldn't have two ways (and 2 places) of telling what we need for our modules to work. Other have pointed some problems with your scheme so I won't repeat them here. I understand what you want to achieve and I think it's good but please keep it in one place. Can't you coordinated your efforts with Module::Build so # old example > my $build = Module::Build->new > ( > module_name => 'Foo::Bar', > license => 'perl', > requires => { > 'perl' => '5.6.1', > 'Some::Module' => '1.23', > 'Other::Module' => '>= 1.2, != 1.5, < 2.0', > }, > ); ... requires => { 'perl' => '5.6.1', 'Some::Module' => 'COMPATIBLE_WITH 1.23', # or the like 'Other::Module' => '>= 1.2, != 1.5, < 2.0', }, Instead for drawing in a new module that most _won't_ use, you make it in the main stream "new" installer. IMO, Module::Build has some problems (which I am sure will be fixed soon) and your proposed module also have some "problems". It would be nice if the versionning /installation questions where handled in a coordinated way. Module devlopers are lazy snakes, they want to sun bath on one stone only! Cheers, Nadim.