module-build-general

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

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

Ken and friends,

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 :)

Cheers, Brian

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.

The good thing about ExtUtils::MakeMaker is that it is powerful,
featureful, flexible, cross-platform and on virtually every installation
of Perl 5. 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.

Unfortunately, ExtUtils::MakeMaker is also stuck with a suboptimal
interface for new Perl authors. Writing a good Makefile.PL requires an
unnecessary level of expertise. Although anything is possible, some
seemingly simple tasks (like distributing scripts) involve a lot of
setup. Complicating the matter is the fact that there is no API for
accessing many of the powerful internals of ExtUtils::MakeMaker.

CPAN::MakeMaker changes everything.

This module is a drop-in replacement for ExtUtils::MakeMaker.
CPAN::MakeMaker works exactly like its legacy counterpart, but it makes
a lot of simple things easier, and some harder things possible.

CPAN::MakeMaker is a self-distributing module. Only the people who want
to create a Perl module or script distribution need to install it. The
first time you run your Makefile.PL, CPAN::MakeMaker will attach itself
to your distribution. The people who end up installing your distribution
don't even need to have into on their system at all. It just works.

You should be able to switch any of your existing module distributions
to CPAN::MakeMaker by simply changing the line:

    use ExtUtils::MakeMaker;

to:

    use CPAN::MakeMaker;

And then run the command 'perl Makefile.PL'. Everything should
just work as before, but now you can take advantage of
CPAN::MakeMaker's additional features. See the CPAN::MakeMaker
documentation for more details.

Make the Switch!

NEW FEATURES

    0.10:
      - Initial Release

INSTALLATION

To install this module type the following:

   perl Makefile.PL
   make
   make test
   make install

COPYRIGHT AND LICENCE

Copyright (C) 2002 Brian Ingerson

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself. 

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

[Dave R. <au...@ur...>]

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.

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.  Think how freaking cool
this would be!  M::B would _just work_, whenever an author chose to use
it.  This would also mean they could always use a minimal passthrough
Makefile.PL and know it'd work with existing versions of CPAN.pm and
future versions (and CPANPLUS too).

Some of the other (todo) features would be nice too, like handling
bundling of other modules and support for making PPMs.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

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

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

On 27/10/02 23:20 -0600, 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.
> 
> 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.

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.

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 also needs to have a compatible version of itself everywhere.
How do you advance? CPAN::MM skirts around this nicely.

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

Most importantly, if you go this route, please don't put M::B in core
Perl. It would be completely illogical, and offer no advantage.

> This could even be the default for Module::Build.  Think how freaking cool
> this would be!  M::B would _just work_, whenever an author chose to use
> it.  This would also mean they could always use a minimal passthrough
> Makefile.PL and know it'd work with existing versions of CPAN.pm and
> future versions (and CPANPLUS too).

I can see a world where authors could choose either M::B or C::MM, or even
both simultaneously!

> Some of the other (todo) features would be nice too, like handling
> bundling of other modules and support for making PPMs.

And it be nicer still if there were a way to share this code. For
instance an author could download a bundling plugin that supported both
M::B and C::M and that code would get stuffed into their distribution
automatically.

See Ken? We shoulda spent more time talking and less time having fun at OSCon
;)

Cheers, Brian

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

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

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

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


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

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

  -Ken

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

[Dave R. <au...@ur...>]

On Mon, 28 Oct 2002, Ken Williams wrote:

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

The problem is that CPAN won't follow through and finish the install of
the module you were trying to install in the first place.

However, I think the proposed Makefile.PL I sent earlier (plus tweaks from
Autrijus) does solve this problem.

Basically, what I want to see is for CPAN or CPANPLUS to be able to
install a Module::Build-using module in _one_ step.

This works right now for CPAN with the Makefile.PL I created.  Adding
support for CPANPLUS to that would probably be trivial.

So I guess I no longer am all excited about the self-install option ;)

Now is someone (cough, Ken) would get back to working on Module::Build
then _I_ could get back to working on it.  Right now I've mostly stopped
looking at it cause my patches are not being integrated.  There's more I'd
like to be able to add/fix but it's difficult to do if there's old patches
still not applied/rejected.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

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

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

On Monday, October 28, 2002, at 08:20  PM, Dave Rolsky wrote:
> Now is someone (cough, Ken) would get back to working on Module::Build
> then _I_ could get back to working on it.  Right now I've mostly stopped
> looking at it cause my patches are not being integrated.  There's more 
> I'd
> like to be able to add/fix but it's difficult to do if there's old 
> patches
> still not applied/rejected.

Yeah.  I'm working more on it now.  Probably shouldn't be, but I am.

  -Ken

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

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

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:

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

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

  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

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.

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

  -Ken

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

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

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

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.

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.

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


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


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

  -Ken