Re: [Module-build-general] MakeMaker Is DOOMED!

[Ken W. <ke...@ma...>]

On Monday, February 17, 2003, at 01:41  PM, Brian Ingerson wrote:
> Not necessarily. It can create both the Makefile and the Build script,
> and then cue the user what to do, especially on non-unix systems.
>

Okay, that sounds reasonable.


> It's a good experiment actually. Module::Build and Test::More are two
> excellent modules that I will probably not use because of the "prereq
> syndrome". I won't add prerequisites to a module unless it is crucial 
> to
> that module's behaviour. And while useful, M::B and T::M are not
> crucial.

Sometimes they are crucial for some projects.  For example, some of my 
modules have "recommended" dependencies that I can't express well using 
MakeMaker.  Crypt::SKey needs either Digest::MD4 *or* Digest::MD5, and 
it can optionally use Term::ReadKey to function as a simple SKey 
command-line calculator.  But the module can be useful with only 
Digest::MD4, for example, so using M::B's more flexible prerequisite 
system means that the user will actually have *fewer* required prereqs 
than under MakeMaker, even if they don't already have M::B installed.

Then there are the cases where in order to get something installed 
correctly, I just can't manage to do the job properly using EU::MM, so 
I have to turn to M::B.

For many of my modules, I've been distributing with both a Makefile.PL 
and a Build.PL, and before too long I'll probably turn the Makefile.PLs 
into pass-throughs when it gets too hectic for me to manage both of 
them.  But I won't do that for crucial modules until M::B is more 
well-known and more widely distributed and tested.


> And I won't have to worry about what versions of T::M and M::B support
> my module's needs because "Hey,  it worked on my system, it almost
> certainly will work everywhere else, because it's the exact same
> version."

And what of the people who have been sending me bug reports that say 
that M::B doesn't work right on Win32, even though I tested it fine on 
my iBook?  Maybe at some future date we'll be able to make modules that 
a) have no unspotted bugs, and b) have no cross-platform issues, but I 
don't think we're there yet.


> If a later version of M::B or T::M is incompatible or broken, it will
> have absolutely no effect on that module I wrote 10 years ago before I
> left the Perl community altogether to pursue a fulltime career in Pizza
> Delivery Management.

So, which do you think is more common: a) an unseen bug in a module 
gets fixed in a future version, or b) a module with no bugs gets broken 
in a future version?  I'd say it's a), and that CP::MM (as described, 
at least) optimizes for the less common case instead of the more common 
one, in a way that would annoy me as a developer or system maintainer.

I think that in the CP::MM project, it will be *crucial* to allow the 
user to use an upgraded version of a module that they've installed more 
recently than the one the developer provided in the bundle, for the 
reasons I described above.  It's really just not true that "it worked 
once for the developer" implies that "it will work for everyone else 
now and forever".

Usually the way people deal with buggy code on their systems is to 
upgrade things using bug-fix releases, but if you keep distributing 
buggy versions cached in CPAN distros people are going to be awfully 
upset.

  -Ken