David Golden wrote:
> On Nov 19, 2007 8:10 AM, David Golden <[EMAIL PROTECTED]> wrote:
>> On Nov 19, 2007 3:12 AM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
>>> ExtUtils::MakeMaker is one of them, and the one that I think seals the deal,
>>> because it's basically not back-compatible, or at least we end up with
>>> ($ExtUtils::MakeMaker::VERSION... ) ? ( ... ) : () inside the prereq_pm key
>>> (presumably...).
>>
>> There are plenty examples of that syntax today. Moreover, adding a
>> new key to META.yml doesn't change that, as module users' machines may
>> not have up-to-date PERL_VERSION compatible EU::MM. From a design
>> flaw perspective -- the fact that the META.yml and dist tarball
>> generator is the same codebase that end-users need to have installed
>> just to make/test/install a module seems to be the bigger problem. It
>> effectively prevents substantial innovation for module authoring in
>> order to preserve compatibility with those installing.
Isn't this exactly the sort of chicken/egg problem that configure_requires is
supposed to solve? So that the Makefile.PL's dependencies can be updated
before the Makefile.PL is run?
Separating the dist builder from the dist installer wouldn't help matters, it
just shoves the problem off one level. Now you have to worry about what
version of the dist installer the end-user has and what it's capabilities are,
just as you do now.
I also note that every other installer in the universe, the very first thing
it does, is it updates the installer. It is usually not an optional thing for
just the sort of chicken/egg problems we worry about. That we leave it an
option is an odd.
--
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
