Re: Module::Install is a time bomb

[Ben Morrow]

Quoth [EMAIL PROTECTED] (Ricardo SIGNES):
> * Ken Williams <[EMAIL PROTECTED]> [2008-10-01T21:34:28]
> > 
> > Ricardo: there's no such thing as "installed latest.pm".  Please go
> > back and read what I wrote above.
> 
> I read and understood what you said.
> 
> Perhaps I should've said, "presumably it would be better if..."
> 
> This thread started with "Module::Install is a time bomb" because, in
> large part, it bundles code that will not use later code found on the
> installing system.  Then when there is a bug, every author must
> re-release a dist.  That means that a fix to Module::Install means
> that there must be a thousand more upgrades, one for each dist using
> it.
> 
> Module::Build is going to fix that by correctly using the latest
> Module::Build -- either the one in ./inc or the one in @INC.  It will
> accomplish that by using code that is only found in the dist.  That
> means that when there is a bug, every author must re-release a dist.
> That means that a fix to latest.pm means that there must be a thousand
> more upgrades, one for each dist using it.
> 
> I will admit that bugs in latest.pm (which I have not seen, but can
> imagine) are less likely than bugs in Module::Install (which I have
> seen, and wish I could not imagine).  It still seems sort of bizarre
> to have absolutely no nuclear option by which one can deal with 1,234
> deployed and broken latest.pms.

Being able to install latest.pm[1] and use an installed version doesn't
help, though. If there's a bug in the section of latest.pm that tries to
locate the installed copy of itself and use it instead, you *still*
can't fix it. And since that is the entire functionality of latest.pm,
there won't ever be any bugs you can fix by installing a fixed version.

[1] IMHO it *really* ought to be called Module::Build::latest, as
otherwise you're stomping on a top-level pragma namespace for the sake
of a module that never gets installed.

Ben

-- 
You poor take courage, you rich take care:
The Earth was made a common treasury for everyone to share
All things in common, all people one.
'We come in peace'---the order came to cut them down.   [EMAIL PROTECTED]

Re: Module::Install is a time bomb

[Aristotle Pagaltzis]

* Ken Williams <[EMAIL PROTECTED]> [2008-10-02 04:10]:
> It's only executed as part of the build system, not ever
> installed. In this respect it's just like any code that's in
> the Build.PL or t/*.t.

But those are written and maintained by the author. Wouldn’t it
make more sense to make latest.pm part of Module::Build proper?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Module::Install is a time bomb

[Ricardo SIGNES]

* Ken Williams <[EMAIL PROTECTED]> [2008-10-01T21:34:28]
> On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES
> >> latest.pm doesn't ever get installed on anyone's computer.  If you
> >> install it, we have a backup plan for that too - the guys in black
> >> coats will come and take your computer away.
> >
> > Well, at this point we're back to "everybody must upgrade everything."
> > Presumably latest.pm knows to use the installed latest.pm if it's later,
> > even if this is rarely true and even more rarely needed.
> 
> Ricardo: there's no such thing as "installed latest.pm".  Please go
> back and read what I wrote above.

I read and understood what you said.

Perhaps I should've said, "presumably it would be better if..."

This thread started with "Module::Install is a time bomb" because, in large
part, it bundles code that will not use later code found on the installing
system.  Then when there is a bug, every author must re-release a dist.  That
means that a fix to Module::Install means that there must be a thousand more
upgrades, one for each dist using it.

Module::Build is going to fix that by correctly using the latest Module::Build
-- either the one in ./inc or the one in @INC.  It will accomplish that by
using code that is only found in the dist.  That means that when there is a
bug, every author must re-release a dist.  That means that a fix to latest.pm
means that there must be a thousand more upgrades, one for each dist using it.

I will admit that bugs in latest.pm (which I have not seen, but can imagine)
are less likely than bugs in Module::Install (which I have seen, and wish I
could not imagine).  It still seems sort of bizarre to have absolutely no
nuclear option by which one can deal with 1,234 deployed and broken latest.pms.

-- 
rjbs

Re: Module::Install is a time bomb

[Ken Williams]

On Wed, Oct 1, 2008 at 8:38 PM, David Golden <[EMAIL PROTECTED]> wrote:
> If I understand correctly, latest.pm isn't a module on CPAN, thus is
> never installed only bundled.
>
> I.e. It's not only::latest (http://search.cpan.org/dist/only-latest)
>
> Correct?

Correct.  It's only executed as part of the build system, not ever
installed.  In this respect it's just like any code that's in the
Build.PL or t/*.t.

 -Ken

Re: Module::Install is a time bomb

[David Golden]

On Wed, Oct 1, 2008 at 9:34 PM, Ken Williams <[EMAIL PROTECTED]> wrote:
> Ricardo: there's no such thing as "installed latest.pm".  Please go
> back and read what I wrote above.

If I understand correctly, latest.pm isn't a module on CPAN, thus is
never installed only bundled.

I.e. It's not only::latest (http://search.cpan.org/dist/only-latest)

Correct?

-- David

Re: Module::Install is a time bomb

[Ken Williams]

On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES
<[EMAIL PROTECTED]> wrote:
> * Ken Williams <[EMAIL PROTECTED]> [2008-10-01T12:15:04]
>> On Wed, Oct 1, 2008 at 11:12 AM, Smylers <[EMAIL PROTECTED]> wrote:
>> > But what if the bundled version of latest.pm is buggy and I already have
>> > a later latest.pm installed on my system?  That will use the wrong one!!
>>
>> latest.pm doesn't ever get installed on anyone's computer.  If you
>> install it, we have a backup plan for that too - the guys in black
>> coats will come and take your computer away.
>
> Well, at this point we're back to "everybody must upgrade everything."
> Presumably latest.pm knows to use the installed latest.pm if it's later, even
> if this is rarely true and even more rarely needed.

Ricardo: there's no such thing as "installed latest.pm".  Please go
back and read what I wrote above.

 -Ken

Re: Module::Install is a time bomb

[Ricardo SIGNES]

* Ken Williams <[EMAIL PROTECTED]> [2008-10-01T12:15:04]
> On Wed, Oct 1, 2008 at 11:12 AM, Smylers <[EMAIL PROTECTED]> wrote:
> > But what if the bundled version of latest.pm is buggy and I already have
> > a later latest.pm installed on my system?  That will use the wrong one!!
> 
> latest.pm doesn't ever get installed on anyone's computer.  If you
> install it, we have a backup plan for that too - the guys in black
> coats will come and take your computer away.

Well, at this point we're back to "everybody must upgrade everything."
Presumably latest.pm knows to use the installed latest.pm if it's later, even
if this is rarely true and even more rarely needed.

-- 
rjbs

Re: Module::Install is a time bomb

[Ken Williams]

On Wed, Oct 1, 2008 at 11:12 AM, Smylers <[EMAIL PROTECTED]> wrote:
>
> But what if the bundled version of latest.pm is buggy and I already have
> a later latest.pm installed on my system?  That will use the wrong one!!

latest.pm doesn't ever get installed on anyone's computer.  If you
install it, we have a backup plan for that too - the guys in black
coats will come and take your computer away.

 -Ken

Re: Module::Install is a time bomb

[Smylers]

Ken Williams writes:

> I'll say it again though: there is no such thing as
> inc::Module::Build.  We're not just putting M::B in an inc/ directory
> and loading it.
> 
> The semantics we're working on for people to use are:
> 
>  use lib 'inc'; # Where latest.pm lives
>  use latest 'Module::Build';  # Knows to look in inc/bundled/
> 
> The general-purpose logic for doing version comparisons lives in latest.pm .

But what if the bundled version of latest.pm is buggy and I already have
a later latest.pm installed on my system?  That will use the wrong one!!

Smylers

Re: Module::Install is a time bomb

[Ken Williams]

On Tue, Sep 30, 2008 at 2:43 AM, Adam Kennedy
<[EMAIL PROTECTED]> wrote:
>
> Really, inc::Module::Build needs to not only be able to know that the
> installed one is newer than it, but that if that is the case it should
> use an entry point to loading Module::Build specifically for that it.

I'll say it again though: there is no such thing as
inc::Module::Build.  We're not just putting M::B in an inc/ directory
and loading it.

The semantics we're working on for people to use are:

 use lib 'inc'; # Where latest.pm lives
 use latest 'Module::Build';  # Knows to look in inc/bundled/

The general-purpose logic for doing version comparisons lives in latest.pm .

 -Ken

Re: Module::Install is a time bomb

[Andreas J. Koenig]

> On Wed, 1 Oct 2008 01:04:02 +0300, "Gabor Szabo" <[EMAIL PROTECTED]> said:

  > BTW Could I somehow install all the dependencies of a module but not
  > the module itself?

You mean like you File::HomeDir requires newest MakeMaker and maybe
more but you don't know exactly and just want to look around the
uninstalled dependencies?

That would be a combination of C and C.

The final step of installing would then be done manually.

-- 
andreas

Re: Module::Install is a time bomb

[Jos I. Boumans]

On Oct 1, 2008, at 5:11 AM, Andreas J. Koenig wrote:

On Wed, 1 Oct 2008 01:04:02 +0300, "Gabor Szabo"  
<[EMAIL PROTECTED]> said:



BTW Could I somehow install all the dependencies of a module but not
the module itself?


You mean like you File::HomeDir requires newest MakeMaker and maybe
more but you don't know exactly and just want to look around the
uninstalled dependencies?

That would be a combination of C and C.

The final step of installing would then be done manually.


CPANPLUS commands can be used for that too of course, and there's even
a plugin for the shell to do just that:

  http://search.cpan.org/~mgrimes/CPANPLUS-Shell-Default-Plugins- 
Prereqs-0.07/lib/CPANPLUS/Shell/Default/Plugins/Prereqs.pm


Cheers,

--

Jos Boumans

"If superman is so smart, why does he wear underpants over his 
trousers?"

CPANPLUShttp://cpanplus.sf.net

Re: Module::Install is a time bomb

[Chris Dolan]

On Sep 30, 2008, at 5:04 PM, Gabor Szabo wrote:


Excuse me?
and you kept this information to yourself all those years?

BTW Could I somehow install all the dependencies of a module but not
the module itself?


Yes, that's what the earlier "test ." recommendation meant.   
Personally, to get deps of darkpan code I usually do "cpan ." and  
then Ctrl-C when I hit the tests in ./t.  Sloppy, but effective.


Chris

Re: Module::Install is a time bomb

[Matt S Trout]

On Tue, Sep 30, 2008 at 04:23:53PM +0200, Johan Vromans wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> 
> > Module::Install is the greatest threat to CPAN stability.
> 
> So why not get rid of it?
> 
> If it does not provide any relevant functionality that EU::MM and M::B
> also provide, it should be possible to convince the author to withdraw
> it.

It provides relevant functionality that isn't available on EUMM any other
way and is very easy to extend - for example, Catalyst apps use a
Module::Install::Catalyst to do some extra stuff that we used to do via
a Module::Build trick but proved kinda fragile due to the Module::Build
dependency problem.

As Adam notes, once configure_requires is widely deployed this becomes a
lot less important - but some of us -do- still like make, for all its evil :)

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

Re: Module::Install is a time bomb

[Matt S Trout]

On Tue, Sep 30, 2008 at 06:53:56PM +0100, Ben Morrow wrote:
> 
> Quoth [EMAIL PROTECTED] ("David Golden"):
> > On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans <[EMAIL PROTECTED]> wrote:
> > > Michael G Schwern <[EMAIL PROTECTED]> writes:
> > >
> > >> Module::Install is the greatest threat to CPAN stability.
> > >
> > > So why not get rid of it?
> > >
> > > If it does not provide any relevant functionality that EU::MM and M::B
> > > also provide, it should be possible to convince the author to withdraw
> > > it.
> > 
> > Personally, I wonder how many authors use it because of the bundling
> > capability and how many use it for the simple declarative syntax for
> > Makefile.PL.
> 
> I use it both for the declarative syntax and because it allows me to
> type
> 
> /path/to/perl Makefile.PL
> make test
> 
> in a dev directory with a fresh install of perl and get all the
> dependencies installed for me. Since I keep lots of versions of perl
> around and try to test my modules on all of them, this is highly
> convenient.
> 
> Of course, if someone were to make all that work using M::B as the
> backend instead of EU::MM, I would be perfectly happy. Probably more so,
> as then extending M::I wouldn't require messing around with EU::MM's
> mess and the hacks required to make M::I work on top of that.

Module::Install used to have a Module::Build backend but nobody cared
enough to maintain it so it bit-rotted and eventually got deleted.

I think Adam and I would both love to see it return if somebody was
willing to give it sufficient love it worked properly again.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

Re: Module::Install is a time bomb

[Sartak]

On Tue, Sep 30, 2008 at 6:04 PM, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> BTW Could I somehow install all the dependencies of a module but not
> the module itself?

make installdeps

I believe this (for some reason) depends on using autoinstall which
has its own problems.

Shawn

Re: Module::Install is a time bomb

[Eric Wilhelm]

# from Austin Schutz
# on Tuesday 30 September 2008 16:54:

>I really appreciate the "real world" attitude.  I regularly have to
>deal with older perls supporting production installed software. I
>don't want to (or can't) upgrade it. 

Is your "it" a) "perl" or  b) "CPAN.pm"?  If one is not allowed to 
upgrade one's perl modules, I think that one cannot be helped with the 
upgrading of one's perl modules.

>I want the modules I use to "work", especially the variety of "work"
>that involves not barfing when I try to install it.

It is unfortunate that any new module on the CPAN is assumed to be the 
latest and greatest and yet the 3-or-4-year-old installer is assumed to 
be ok because that's what the OS shipped with or whatever?

  cpan CPAN

You can do that without needing to upgrade your perl.  Then you have 
configure_requires support and henceforth any brand-new thing which 
happens to be required during installation of the brand-new thing you 
want will be conveniently installed for you.

Of course it would be easier for you if we did that for you, but that 
has some complications so how's about you do it and tell your friends 
to do likewise?

Thanks,
Eric
-- 
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
---
http://scratchcomputing.com
---

Re: Module::Install is a time bomb

[Andreas J. Koenig]

> On Tue, 30 Sep 2008 18:53:56 +0100, Ben Morrow <[EMAIL PROTECTED]> said:

 >> Personally, I wonder how many authors use it because of the bundling
 >> capability and how many use it for the simple declarative syntax for
 >> Makefile.PL.

  > I use it both for the declarative syntax and because it allows me to
  > type

  > /path/to/perl Makefile.PL
  > make test

  > in a dev directory with a fresh install of perl and get all the
  > dependencies installed for me. Since I keep lots of versions of perl
  > around and try to test my modules on all of them, this is highly
  > convenient.



You should try

/path/to/perl^Wcpan . # <--- the last character is a dot

instead. More than 22 strokes less to type and no shift key.

  > Of course, if someone were to make all that work using M::B as the
  > backend instead of EU::MM, I would be perfectly happy. Probably more so,
  > as then extending M::I wouldn't require messing around with EU::MM's
  > mess and the hacks required to make M::I work on top of that.

cpan works with EUMM and MB and MI.



-- 
andreas

Re: Module::Install is a time bomb

[Austin Schutz]

> You mean like how Module::Build broke over a YAML release and we spent over
> a year cleaning up after it because every single user who ran into that
> version mismatch had to have the problem explained to them?
> 
> I still regularly see -ancient- versions of Module::Build installed lots of
> places, often pre-INSTALL_BASE-behaviour-change, which causes great fun when
> I upgrade it past that release.
> 
> I know that's crap. I know it's sad. But it's the real world, and I live in
> it.
>  

You guys are way beyond me when it comes to understanding this stuff.

But as the average dodo, I really appreciate the "real world" attitude.
I regularly have to deal with older perls supporting production installed
software. I don't want to (or can't) upgrade it. I want the modules I use 
to "work", especially the variety of "work" that involves not barfing when I
try to install it.
If autobundling (or whatever) solves that problem, then yay for that
solution, as long as the amount of extra space involved isn't completely
onerous.
Essentially I agree with that f-word laden run on sentence you
espoused earlier. Please to just be working.

Austin

Re: Module::Install is a time bomb

[Matt S Trout]

On Mon, Sep 29, 2008 at 01:59:09PM -0400, Michael G Schwern wrote:
> Matt S Trout wrote:
> > use inc::Module::Install;
> 
> I will say it again:  Module::Install is the greatest threat to CPAN 
> stability.
> 
> Module::Install bundles itself, but will not use a newer installed version.
> [1]  At some point something is going to happen which will break
> Module::Install.  A subtle perl upgrade bug, some new operating system quirk,
> a dependency change, or more probably, MakeMaker will change something in its
> guts and one of the many hacks MI does will no longer work.

You mean like how Module::Build broke over a YAML release and we spent over
a year cleaning up after it because every single user who ran into that
version mismatch had to have the problem explained to them?

I still regularly see -ancient- versions of Module::Build installed lots of
places, often pre-INSTALL_BASE-behaviour-change, which causes great fun when
I upgrade it past that release.

I know that's crap. I know it's sad. But it's the real world, and I live in
it.
 
> At that point every dist which bundles MI will fail and we will have to wait
> while every one of them releases an update.  From experience, this is a very,
> very slow process which will have repercussions for months and years after the
> initial OMGUBROKECPAN event.

>From experience, most actively maintained stuff fixes itself quite quickly.

Anything that doesn't isn't actively maintained and is vulnerable to the same
problem with every line of its own code as well.

However, I think it's becoming fairly evident that to all intents and
purposes we're arguing a matter of opinion here, so since I think we've
now both stated our arguments pretty clearly I'm going to bow out of the
thread at this point, and hope that if you agree with this paragraph, you'll
agree to disagree on the rest of the points.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

Re: Module::Install is a time bomb

[Hans Dieter Pearcey]

On Wed, Oct 01, 2008 at 01:04:02AM +0300, Gabor Szabo wrote:
> BTW Could I somehow install all the dependencies of a module but not
> the module itself?

Within the CPAN shell, running tests would probably do it.  Configuring might
too.

hdp.

Re: Module::Install is a time bomb

[Chris 'BinGOs' Williams]

On Tue, Sep 30, 2008 at 02:38:03PM -0400, David Golden wrote:
> On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow <[EMAIL PROTECTED]> wrote:
> > I use it both for the declarative syntax and because it allows me to
> > type
> >
> >/path/to/perl Makefile.PL
> >make test
> >
> > in a dev directory with a fresh install of perl and get all the
> > dependencies installed for me. Since I keep lots of versions of perl
> > around and try to test my modules on all of them, this is highly
> > convenient.
> 
> Is that with auto-install?  I guess I can see that purpose, though
> auto-install can be a real annoyance to end-users otherwise.
> 
> I'd probably do it this way with a recent version of CPAN.pm:
> 
>$ /path/to/perl -MCPAN -e shell
>cpan> test .
> 
> No Module::Install or auto-install required.

That is f**king scary.

-- 
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk
==


pgppApL9Oiyzd.pgp
Description: PGP signature

Re: Module::Install is a time bomb

[Ben Morrow]

[just sent to module-authors, as this is hardly a p5p matter any more]

Quoth [EMAIL PROTECTED] ("David Golden"):
> On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow <[EMAIL PROTECTED]> wrote:
> > I use it both for the declarative syntax and because it allows me to
> > type
> >
> >/path/to/perl Makefile.PL
> >make test
> >
> > in a dev directory with a fresh install of perl and get all the
> > dependencies installed for me. Since I keep lots of versions of perl
> > around and try to test my modules on all of them, this is highly
> > convenient.
> 
> Is that with auto-install?  I guess I can see that purpose, though
> auto-install can be a real annoyance to end-users otherwise.

Yes, it is. Auto-install can be useful to end users, of course, when
installing something that isn't on CPAN but has CPAN dependancies; but
the annoyance I can certainly see. Back before M::I played nicely with
a running CPAN shell it used to be *incredibly* annoying, particularly
on Win32.

> I'd probably do it this way with a recent version of CPAN.pm:
> 
>$ /path/to/perl -MCPAN -e shell
>cpan> test .

I didn't know about that: thanks.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?  (Fiona Apple)
* [EMAIL PROTECTED] *

Re: Module::Install is a time bomb

[Ben Morrow]

Quoth [EMAIL PROTECTED] ("David Golden"):
> On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans <[EMAIL PROTECTED]> wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> >
> >> Module::Install is the greatest threat to CPAN stability.
> >
> > So why not get rid of it?
> >
> > If it does not provide any relevant functionality that EU::MM and M::B
> > also provide, it should be possible to convince the author to withdraw
> > it.
> 
> Personally, I wonder how many authors use it because of the bundling
> capability and how many use it for the simple declarative syntax for
> Makefile.PL.

I use it both for the declarative syntax and because it allows me to
type

/path/to/perl Makefile.PL
make test

in a dev directory with a fresh install of perl and get all the
dependencies installed for me. Since I keep lots of versions of perl
around and try to test my modules on all of them, this is highly
convenient.

Of course, if someone were to make all that work using M::B as the
backend instead of EU::MM, I would be perfectly happy. Probably more so,
as then extending M::I wouldn't require messing around with EU::MM's
mess and the hacks required to make M::I work on top of that.

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints |   Than ever was born
   In one room together,  |   Out of all of the conflicts of time.
[EMAIL PROTECTED]The Levellers, 'Believers'

Re: Module::Install is a time bomb

[Adam Kennedy]

2008/9/30 Michael G Schwern <[EMAIL PROTECTED]>:
> chromatic wrote:
>> s/Module::Install/Autobundling/
>>
>> Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside
>> applications, but the CPAN is not the place for static linking.  It would be
>> nice not to drag Perl kicking and screaming back into the 1970s.
>
> Autobundling is fine AS LONG AS the bundled version gives way to a newer
> installed version.

I suspect needs to be a little bit more robust than just giving way
because that doesn't give you proper "reach back in time" capability.

Really, inc::Module::Build needs to not only be able to know that the
installed one is newer than it, but that if that is the case it should
use an entry point to loading Module::Build specifically for that it.

That would avoid cluttering up the regular M:B bootstrap, and let you
concentrate all the compatibility weirdness for handling old bundled
stuff in one separate place.

So then you get

use inc::Module::Build;

... which loads...

use Module::Build::BundleCompany;

... which then has the option of doing various things before actually loading...

use Module::Build;

... and returning back to the Build.PL code.

The key theme to all this new stuff is that it should be able to reach
back in time on it's own and pull forwards anything we don't currently
know is broken. Making a specific place for current-MB to trigger
future-MB seems like a nice extra safeguard, since we have the chance
to build it in from the beginning.

Adam K

Re: Module::Install is a time bomb

[Adam Kennedy]

2008/9/30 Michael G Schwern <[EMAIL PROTECTED]>:
> That said, people choose based on convenience, not abstract, long term safety.
>  So it's for the best that Module::Build absorb every convenience feature 
> from MI.

For the record, I concur entirely with this solution.

Module::Install was a step forwards for adding new functionality to
configuration scripts given the alternatives. Since these arguments
often go in circles, a quick reminder where we are right now.

ExtUtils::MakeMaker
Change Solution: Never change, bug fix as lightly as possible.
Short Term: Just Works, authors need lots of if ( $] >= 5.005 ) cruft
Long Term: Slow death by obsolescence.

Module::Build
Change Solution: All users hand-upgrade without being told when
Short Term: Modules don't build on the default Perl install
Long Term: New features can't be used + OMGIBROKECPAN kills CPAN till
every user upgrades.

Module::Install
Change Solution: Bundle everything, assume the author releases a lot
Short Term: Works Fine
Long Term: Old Releases go toxic + OMGIBROKECPAN kills CPAN till every
author upgrades (or the modules are taken over).

configure_requires:
Change Solution: Client knows when to upgrade toolchain
Short Term: Needs 100% support from toolchain, THEN we tell users
"just upgrade Bundle::CPAN" (a current somewhat learned behaviour when
installs break anyway)
Long Term: configure_requires available in the default install from
5.8.9 and 5.10.1. Just Works.

I'd be more than happy to shift Module::Install over to Module::Build,
or (more likely) to have a clone of the far nicer interface that sits
on Module::Build.

It's just that Module::Build fails now, and Module::Install fails
later (but more dramatically). And I'm biased towards things working
now, as long as everyone is clear that it's just a workaround now,
till the better option is delivered.

Now that M:B and EU:MM and M:I and CPAN.pm all support
configure_requires, it is safe to start telling CPAN.pm users "just
upgrade your Bundle::CPAN".

I just don't want to make a lot of noise about this until we finally
get CPANPLUS over the line, and have everything synced to core for the
next releases.

Jos says that CPANPLUS svn is fairly close to being stable, and wants
people to test it. The faster we can get the next CPANPLUS stable over
the line, and everything synced back to core, the faster we can start
the clock on the 1 year that we still need to tread cautiously but
generally can just tell people to upgrade Bundle::CPAN.

Adam K

Re: Module::Install is a time bomb

[chromatic]

On Monday 29 September 2008 10:59:09 Michael G Schwern wrote:

> Matt S Trout wrote:
> > use inc::Module::Install;

> I will say it again:  Module::Install is the greatest threat to CPAN
> stability.

s/Module::Install/Autobundling/

Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside 
applications, but the CPAN is not the place for static linking.  It would be 
nice not to drag Perl kicking and screaming back into the 1970s.

I'm still trying to figure out what's the problem with adding '0.31' to 
the 'use Module::Build;' line in a Build.PL, and how autobundling could 
possibly be ever a good idea in a CPAN distribution.

-- c

Re: Module::Install is a time bomb

[Gabor Szabo]

On Tue, Sep 30, 2008 at 9:57 PM, Andreas J. Koenig
<[EMAIL PROTECTED]> wrote:
>> On Tue, 30 Sep 2008 18:53:56 +0100, Ben Morrow <[EMAIL PROTECTED]> said:
>
>  >> Personally, I wonder how many authors use it because of the bundling
>  >> capability and how many use it for the simple declarative syntax for
>  >> Makefile.PL.
>
>  > I use it both for the declarative syntax and because it allows me to
>  > type
>
>  > /path/to/perl Makefile.PL
>  > make test
>
>  > in a dev directory with a fresh install of perl and get all the
>  > dependencies installed for me. Since I keep lots of versions of perl
>  > around and try to test my modules on all of them, this is highly
>  > convenient.
>
> 
>
> You should try
>
>/path/to/perl^Wcpan . # <--- the last character is a dot
>
> instead. More than 22 strokes less to type and no shift key.
>
>  > Of course, if someone were to make all that work using M::B as the
>  > backend instead of EU::MM, I would be perfectly happy. Probably more so,
>  > as then extending M::I wouldn't require messing around with EU::MM's
>  > mess and the hacks required to make M::I work on top of that.
>
> cpan works with EUMM and MB and MI.
>
> 

Excuse me?
and you kept this information to yourself all those years?

BTW Could I somehow install all the dependencies of a module but not
the module itself?

thanks and regards
  Gabor

Re: Module::Install is a time bomb

[Ken Williams]

On Tue, Sep 30, 2008 at 1:38 PM, David Golden <[EMAIL PROTECTED]> wrote:

> I'd probably do it this way with a recent version of CPAN.pm:
>
>   $ /path/to/perl -MCPAN -e shell
>   cpan> test .

That's pretty awesome.  Andreas++.

 -Ken

Re: Module::Install is a time bomb

[David Golden]

On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow <[EMAIL PROTECTED]> wrote:
> I use it both for the declarative syntax and because it allows me to
> type
>
>/path/to/perl Makefile.PL
>make test
>
> in a dev directory with a fresh install of perl and get all the
> dependencies installed for me. Since I keep lots of versions of perl
> around and try to test my modules on all of them, this is highly
> convenient.

Is that with auto-install?  I guess I can see that purpose, though
auto-install can be a real annoyance to end-users otherwise.

I'd probably do it this way with a recent version of CPAN.pm:

   $ /path/to/perl -MCPAN -e shell
   cpan> test .

No Module::Install or auto-install required.

-- David

Re: Module::Install is a time bomb

[David Golden]

On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans <[EMAIL PROTECTED]> wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>> Module::Install is the greatest threat to CPAN stability.
>
> So why not get rid of it?
>
> If it does not provide any relevant functionality that EU::MM and M::B
> also provide, it should be possible to convince the author to withdraw
> it.

Personally, I wonder how many authors use it because of the bundling
capability and how many use it for the simple declarative syntax for
Makefile.PL.

-- David

Re: Module::Install is a time bomb

[Johan Vromans]

Michael G Schwern <[EMAIL PROTECTED]> writes:

> Module::Install is the greatest threat to CPAN stability.

So why not get rid of it?

If it does not provide any relevant functionality that EU::MM and M::B
also provide, it should be possible to convince the author to withdraw
it.

-- Johan

Re: Module::Install is a time bomb

[David Coppit]

chromatic wrote:


... and how autobundling could possibly be ever a good idea in a CPAN
distribution.


Is autobundling not a nice solution for non-standard modules that you need
for your build? For example, my Module::Install::GetProgramLocations
provides a standard way for finding the correct version of external
programs a module might need. One can use this module to set the paths in
Config.pm and then continue the install as normal.

David

_
David Coppit   http://coppit.org/

Re: Module::Install is a time bomb

[Michael G Schwern]

chromatic wrote:
> s/Module::Install/Autobundling/
> 
> Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside 
> applications, but the CPAN is not the place for static linking.  It would be 
> nice not to drag Perl kicking and screaming back into the 1970s.

Autobundling is fine AS LONG AS the bundled version gives way to a newer
installed version.


> I'm still trying to figure out what's the problem with adding '0.31' to 
> the 'use Module::Build;' line in a Build.PL, and how autobundling could 
> possibly be ever a good idea in a CPAN distribution.

Because it requires manual intervention to fix, even if it only has to be
fixed once per install, and we don't like that.


-- 
39. Not allowed to ask for the day off due to religious purposes, on the
basis that the world is going to end, more than once.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/