Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

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

On 28/10/02 16:56 -0600, Ken Williams wrote:

Ken, 

Thanks for looking over CPAN::MakeMaker and commenting. I know that the
CPAN::MakeMaker way of thinking is counterintuitive to the traditional
Perl way of thinking. (Especially to somebody in the midst of writing a
new traditional Perl build system.) But I really think it makes the most
sense as I will attempt to explain. Stay with me here...

> On Sunday, October 27, 2002, at 11:20  PM, Dave Rolsky wrote:
> > On Sun, 27 Oct 2002, Brian Ingerson wrote:
> >
> >> FYI. (NOTE: Even though this seems like a competitive module, I
> >> really think that Module::Build and CPAN::MakeMaker are somewhat
> >> orthoganal. I'm looking forward to working together. There is a good
> >> chance that these modules could nicely complement each other. Let the
> >> thinking begin :)
> >
> > I like that self-instaling feature.  I wonder if we could/should
> > incorporate that for Module::Build.
> 
> I'm generally against "auto-installing" things.  I was going to ask what 
> mechanism CPAN::MakeMaker actually uses to "just work", since I can 
> think of at least three:

CP::MM doesn't auto-install anything at all on the USER system. On the
AUTHOR system, it simply adds a file called ./CPAN/MakeMaker to your
working directory and updates your MANIFEST. It does this because the
AUTHOR asked it to, (implicitly) by using CPAN::MakeMaker in their
Makefile.PL. (I could make it explicit but I feel that would be error
prone in the long run.)

A USER will never have CP::MM on their system at all. (Unless they are
also an AUTHOR. :)

>   1) viral: it auto-installs itself on the host system

Not viral. Doesn't install on USER system.

>   2) catalyst: it doesn't need to be installed, it just needs to be 
> present when installing.

Right. That's the ticket!

>   3) stealth: it isn't even present in the tarballs that use it, it just 
> inserts/changes a bunch of code in the tarballs so they can do what they 
> need to do

Yucky :)

> I'm against doing #1 for M::B.  #2 is fine in principal, as long as 
> newer versions on the system would still be honored.  #3 is kind of 
> yucky.

Good.

> > Maybe we could offer a 'Build uberdist' feature or something that would
> > simply incorporate all of the M::B files into the tarball.  As long as
> > they end up untarring into the top-level of the distro (./Module,
> > ./Module/Base.pm, etc) it'd just work.
> >
> > This could even be the default for Module::Build.
> 
> I'm not crazy about the idea that using M::B would bloat your 
> distribution with its own by default.  In my mind this is better solved 
> by getting dependency relationships that express the situation 
> correctly, then letting the user (or automated system) resolve those 
> dependencies.  That leaves you with a better dependency map too.

My hope is that CP:MM will get to where it can build a custom version of
itself that only includes code for the features that the AUTHOR has
used. So any bloat, would only be *necessary* bloat. And if you think
about it, the AUTHOR is no longer going to need to write a lot of code
to do the stuff that the "bloat" is now doing. So it may end up that
overall, there is no difference in distribution size.

You are right about getting the dependency mapping right. I hope to offer
some good options here and hopefully ones that are compatible with M::B. 

On 28/10/02 17:14 -0600, Ken Williams wrote:
>
> On Sunday, October 27, 2002, at 07:48  PM, Brian Ingerson wrote:
> > CPAN/MakeMaker version 0.10
> > ===========================
> >
> > The module ExtUtils::MakeMaker is familiar to everybody. It's on the
> > first line of every Makefile.PL of every module distribution on CPAN.
>
> Well, most of them.
>
> Anyway, I do think this is a bit of a step backwards.  I don't really
> like the idea of including CPAN::MakeMaker in every module distributed,
> but that's largely an aesthetic argument against making zillions of
> distributions with the same installation code, and having to deal with
> the associated problems with it.

If I get to the point where CP::MM is custom, then there won't be
hundreds (there aren't a zillion distros yet :) of copies of the same
code. It will be exactly the code that is right for each distro. And
less custom code rewritten by each AUTHOR.

And remember, in XP terms, duplication is OK as long as there is only
one canonical copy, and other copies are derivative. This is actually a
large scale refactoring and code reduction for CPAN. That's SOOO cool!

> Also, one of the main reasons I aborted my project to "fix" EU::MM was
> that I became convinced that its OO architecture is bad (upside-down,
> mostly) and unfixable.  I'm concerned that CPAN::MM will be like trying
> to patch a turd.

My plan is to build a wrapper OO architecture that is right side up and
fixable. It doesn't matter so much what the underlying turds are. 

I must also say that I rather like EU::MM for the fact that it does so much
(even if it does it in an arcane manner). The beauty of EU::MM is that there
is a common code base to leverage on every installation of Perl 5. You just
can't ignore that.

> I don't mean to discourage you from working on it, but these are my
> reservations about its success.

In the final analysis, nobody has to use CP::MM or M::B. If they are
useful they probably will get used, and if they aren't they probably
won't. That's just Perl.

> > The good thing about ExtUtils::MakeMaker is that it is powerful,
> > featureful, flexible, cross-platform and on virtually every installation
> > of Perl 5.
>
> That's also true of the other ExtUtils::* modules, which I happily use
> in Module::Build.
>
> > The bad thing about this legacy workhorse is that the Perl
>
> > The bad thing about this legacy workhorse is that the Perl
> > community is crippled to significantly improve it. Any features added
> > now can only enhance the current release of Perl. Authors would shun new
> > features anyway, because their modules could not be used in earlier
> > versions of Perl that account for the overwhelming majority of
> > installations.
>
> So why not just add new features to ExtUtils::MakeMaker and put that
> in ./ of each module that wants to use the new features?

Too big. I can be stealth. 

Also, since EU::MM is already on every system the old one would get
executed, because '.' is at the end of @INC. EU::MM doesn't know to load
the local one like CP::MM does.

> > CPAN::MakeMaker is a self-distributing module.
>
> After reading your documentation and seeing that it's not viral, I'd
> change the above phrase.  I assumed it was viral when I read this.

Good point.


On 28/10/02 17:22 -0600, Ken Williams wrote:
>
> On Monday, October 28, 2002, at 12:42  AM, Brian Ingerson wrote:
> > You have to make sure that an *installed* copy of M::B reloads the local
> > copy. The installed version will always be found first. But ultimately,
> > it's the local copy you want to execute, because that is the one that
> > the module author configured his distribution for. This is *essential*.
> > If you do it, you'll never have versioning problems. If you don't you'll
> > be plagued by them.
>
> Suppose there's a security bug in M::B, though - if I adopt the above
> policy, a user couldn't just update M::B on their system to fix the
> bug.  They'd also have to make sure all software they installed later
> that uses M::B also had a fixed version.  That

That's the problem that I see with M::B. You have to get it everywhere,
and upgrade it everywhere. Making it yet another dependency is going to
get irksome, IMO. As an AUTHOR, I'm not willing to risk the excess
dependency stigma for my modules if I can avoid it. Especially for my
less known modules.

If there is a security problem, then with M::B you have a zillion copies
of the problem out there (there actually *are* a zillion installations
of Perl ;).

With CP::MM you don't have any insecure code on the USER systems. You
have a handful of copies of the problem inside some AUTHOR's distros.
And only the ones who have packaged with a bad copy of CP::MM. They
simply redistribute their distros with the fixed CP::MM and the *entire*
security problem is eliminated. No messy residue!

And all the AUTHORs will find out about the bug much sooner than all the
USERs would. Because the first USER to get bit by the bug is going to
bite the AUTHOR in a heartbeat!

> > One problem the current M::B faces is that it not only needs to get a
> > copy of M::B on every install (an extremely formidable task in its own
> > right)
>
> It's not too hard.  The current pass-through Makefile.PL lists M::B as a
> dependency, so CPAN.pm (and similar) will install it.

Am I the only one who still installs their modules by hand? I hate
dependencies, but not as much as shell utilities that are awkward to set
up, sometimes flaky, and worst of all need to be run as root.

FWIW, on Unix w/ sudo, I can do an entire installation of a module (with
no dependencies) safely, using a simple bash function. With dependencies
I'd probably have to write it in Perl and pretty soon we'd have yet
another CPAN shell :P

> > it also needs to have a compatible version of itself everywhere.
> > How do you advance?
>
> By having authors list the required version of M::B as a build
> dependency.
>
>
> > If you do the self install route, you have one other issue to tackle.
> > What happens to all the existing M::B installs? They don't know how to
> > play the game. They must be removed, or you must change your module
> > What happens to all the existing M::B installs? They don't know how to
> > play the game. They must be removed, or you must change your module
> > name. I ran into this problem with Inline::MakeMaker, the precedent to
> > C::MM. I was going to need to find a way to nuke the old ones. Now I'm
> > saved by the fact that I can move all the planned Inline logic into
> > C::MM which doesn't (and won't) have legacy problems.
>
> Hmm, seems like the same thing can just happen with CPAN::MM later,
> though.

I'd certainly like to know how. Since it never installs on the USER
side, there is *no legacy* by definition. I could put out a completely
different UI/API every day until the end of time, and never break
anything. I wouldn't do that, but theoretically I could.

Only the AUTHOR needs to know about the current CP::MM feature set,
which is always in the current POD documentation.

> > See Ken? We shoulda spent more time talking and less time having fun at
> > OSCon
> > ;)
>
> I tend not to plan things very well in person, though, which generally
> makes me useless face-to-face. ;-)

But we sure did have fun! :D

Cheers, Brian