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.





Reply via email to