Re: Module::Install is a time bomb

2008-10-01 Thread Eric Wilhelm
# from Ricardo SIGNES # on Wednesday 01 October 2008: >* 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

Re: Module::Install is a time bomb

2008-10-01 Thread 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 s

Re: Module::Install is a time bomb

2008-09-30 Thread 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

Re: Module::Install is a time bomb

2008-09-30 Thread 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 > pl

Re: Module::Install is a time bomb

2008-09-30 Thread 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 ste

Re: Module::Install is a time bomb

2008-09-30 Thread 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 s

Re: Module::Install is a time bomb

2008-09-30 Thread 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 v

Re: Module::Install is a time bomb

2008-09-30 Thread 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-p

Re: Module::Install is a time bomb

2008-09-29 Thread 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 f