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.
