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

[Brian I. <in...@tt...>]

On 17/02/03 14:09 -0600, Ken Williams wrote:
> 
> 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.

I agree with all this. I am definitely in favor of M::B over EU::MM. And
in a perfect world, every Perl module would use a perfect version of
M::B that was installed on every installation of Perl. But we ain't
there yet. The technical and social bootstrapping is going to be a long
and winding road with many cats to shepard. I'm looking for ways to
abstract over both systems to smooth the transition. I hope that one day
(not too far away) CP::MM is a wrapper over completely over M::B instead
of both systems.

  (EU) MakeMaker is Dead. Long live (CP) MakeMaker. ;)

> > 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.

Right. This is assuming a more mature M::B of course. But we're getting
there relatively fast no?

> > 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.

I see what you are saying, but here's the deal: If a bug is found in a
bundled installation support module like T::M or M::B, and it is known
to be fixed in a later version, there is ONE EXACT POINT of contact in
the entire universe. And we know her email address by definition.

Email the (CP::MM using) module author and tell them to re-release with
the fixed version and the worldwide problem is fixed for everyone in one
fell swoop. And this will take the author all of 5 minutes to do.

No need to hunt down and inform the thousands of M::B installees with a
busted version.

So I'll have to disagree with you here. It is *crucial* that CP::MM
always respects its private environment. That is the central theme
of CP::MM.

---

Now, that said, an inquisitive young sysadmin could simply run:

    make reset
    perl Makefile.PL

And CP::MM would reset the distro as if that person were the author.
They could fiddle with it until it worked on their platform and then
report their findings back to the real author.

Cheers, Brian

PS I really do like/support Module::Build. Keep up the good work.