Re: Old and broken versions of Module::Install

[Steffen Mueller]

Steffen Mueller schrieb:
You 
can find a complete (and somewhat current) list of problematic modules 
at http://steffen-mueller.net/mi_old.html


I have just completed rerunning the script that generated that list. The 
new list is available at above URL.


Steffen

Re: Old and broken versions of Module::Install

[Adam Kennedy]

James E Keenan wrote:

Steffen Mueller wrote:
 You
can find a complete (and somewhat current) list of problematic modules 
at http://steffen-mueller.net/mi_old.html




Thank you very much for this public service!


Indeed.

Adam K

Re: Old and broken versions of Module::Install

[James E Keenan]

Steffen Mueller wrote:
 You
can find a complete (and somewhat current) list of problematic modules 
at http://steffen-mueller.net/mi_old.html




Thank you very much for this public service!

jimk

Re: Old and broken versions of Module::Install

[Adam Kennedy]

I understand the concerns with M::B itself; that’s why I always
use `create_makefile_pl => 'traditional'`.


Indeed, and if you insist on using Module::Build, that is most certainly 
the sanest approach.


Adam K

Re: Old and broken versions of Module::Install

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-07-07 00:00]:
> If you ONLY use the basic functionality, and you aren't willing
> to pay attention, you should be using EU:MM still, until either
> MB or or MI hits 1.0, because neither of them are ready for
> general use.

Manual inspection has always suggested that the Makefile.PL
generated for me by M::B::Compat is sane enough. Given that, I’d
prefer to stick with it so I don’t have to do much of anything at
the time that M::B hits both 1.0 and core.

I understand the concerns with M::B itself; that’s why I always
use `create_makefile_pl => 'traditional'`.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Old and broken versions of Module::Install

[Adam Kennedy]

But you’re not catching me dead using an installer that requires
me to pay attention to its development and to push up new
versions of my distros in response to its bugs. There are far
better ways to waste my time.


Good, because that's entirely the point I've been trying to make ever 
since I started doing maint releases of Module::Install.


Module;:Install is not finished (at 1.0) and until it is if you want to 
take advantage of it as an early user, you should be willing to do the 
occasional incremental release if something big comes up.


Module::Build is not finished (at 1.0) and until it is if you want to 
take advantage of it as an early user, and you use ::Compat, you should 
be willing to do the occasional incremental release if something big 
comes up.


If you ONLY use the basic functionality, and you aren't willing to pay 
attention, you should be using EU:MM still, until either MB or or MI 
hits 1.0, because neither of them are ready for general use.


I find it unfortunate that hype on both sides resulted in what I would 
consider overuse this early in their development, but there you go...


Adam K

Re: Old and broken versions of Module::Install

[demerphq]

On 7/6/06, David Golden <[EMAIL PROTECTED]> wrote:

Steffen Mueller wrote:
> Michael G Schwern schrieb:
>> What's broken and why suddenly 5.8.8?
>
> * ActivePerl::Config on case-insensitive filesystems interacts
>   erroneously with Module::Install's (outdated) @INC hack, so remove it.
>   (Patch from Gisle Aas)
> [...]
>
> Sounds like its a combination of an M::I hack and Windows being the bad
> platform its often perceived as.

I take issue with the "bad platform" bit.  The underlying issue is Perl
developers who assume unix semantics (perhaps unconsciously, even) and
don't write for portability.

The Vanilla Perl project (vanillaperl.com) has been squashing numerous
bugs of this sort in CPAN modules.  There are surprisingly many
forward/backslash bugs, even by developers who should know better.  Many
of them crop up in test-suites, even when the code itself uses File::Spec.


Hear, hear!

Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Old and broken versions of Module::Install

[Steffen Mueller]

Jan Dubois schrieb:

Module::Install version 0.60 and earlier pushes one of its own
directories to the front of @INC, and that directory contains Base.pm or
BASE.pm, shadowing the core base.pm on case insensitive filesystems
(Windows, OS X).


Thank you for the explanation. I wasn't aware of this.


ActivePerl 5.8.7 build 815 and later load additional code in Config.pm
to automatically adjust to using dmake and gcc if nmake and/or the
Microsoft compiler cannot be found on the PATH.  This allows you to use
MingW with ActivePerl out of the box with zero configuration required.


Which is great, by the way.


One of the modules used in the ActivePerl::Config code use 'base.pm',
which breaks if it cannot load the core version anymore.

This has been fixed in Module::Install version 0.61:

http://rt.cpan.org/Public/Bug/Display.html?id=18181

I've also modified the code in ActivePerl to not use base.pm in any
of the modules loaded by Config.pm, so starting with build 818 you
should be able to install CPAN modules with the broken Module::Install
again.


While that's also great, I still think the old Module::Install versions 
lying around on CPAN are prone to blow up eventually and need a fix.


Steffen

Re: Old and broken versions of Module::Install

[David Golden]

Steffen Mueller wrote:

Michael G Schwern schrieb:

What's broken and why suddenly 5.8.8?


* ActivePerl::Config on case-insensitive filesystems interacts
  erroneously with Module::Install's (outdated) @INC hack, so remove it.
  (Patch from Gisle Aas)
[...]

Sounds like its a combination of an M::I hack and Windows being the bad 
platform its often perceived as.


I take issue with the "bad platform" bit.  The underlying issue is Perl 
developers who assume unix semantics (perhaps unconsciously, even) and 
don't write for portability.


The Vanilla Perl project (vanillaperl.com) has been squashing numerous 
bugs of this sort in CPAN modules.  There are surprisingly many 
forward/backslash bugs, even by developers who should know better.  Many 
of them crop up in test-suites, even when the code itself uses File::Spec.


The M::I hack doesn't help, but probably neither does AS's config hacking.

David Golden

RE: Old and broken versions of Module::Install

[Jan Dubois]

On Thu, 06 Jul 2006, Michael G Schwern wrote:
> On 7/6/06, Steffen Mueller <[EMAIL PROTECTED]> wrote:
> > Versions of Module::Install < 0.61 do not work on the current
> > ActivePerl release 5.8.8 build 817.
>
> What's broken and why suddenly 5.8.8?

Module::Install version 0.60 and earlier pushes one of its own
directories to the front of @INC, and that directory contains Base.pm or
BASE.pm, shadowing the core base.pm on case insensitive filesystems
(Windows, OS X).

ActivePerl 5.8.7 build 815 and later load additional code in Config.pm
to automatically adjust to using dmake and gcc if nmake and/or the
Microsoft compiler cannot be found on the PATH.  This allows you to use
MingW with ActivePerl out of the box with zero configuration required.

One of the modules used in the ActivePerl::Config code use 'base.pm',
which breaks if it cannot load the core version anymore.

This has been fixed in Module::Install version 0.61:

http://rt.cpan.org/Public/Bug/Display.html?id=18181

I've also modified the code in ActivePerl to not use base.pm in any
of the modules loaded by Config.pm, so starting with build 818 you
should be able to install CPAN modules with the broken Module::Install
again.

Cheers,
-Jan

Re: Old and broken versions of Module::Install

[Steffen Mueller]

Michael G Schwern schrieb:

On 7/6/06, Steffen Mueller <[EMAIL PROTECTED]> wrote:

Versions of Module::Install < 0.61 do not work on the current ActivePerl
release 5.8.8 build 817.


What's broken and why suddenly 5.8.8?


ActiveState introduced some new form of local configuration or 
something. Module::Install couldn't handle it until 0.61. M::I's change 
log would have told you:


[Changes for 0.61 - 2006-03-15]

* ActivePerl::Config on case-insensitive filesystems interacts
  erroneously with Module::Install's (outdated) @INC hack, so remove it.
  (Patch from Gisle Aas)
[...]

Sounds like its a combination of an M::I hack and Windows being the bad 
platform its often perceived as.


5.8.8 because AS Perl build 817 *is* 5.8.8. Build 816 was the first 
5.8.8 build and a "bad" build (some symbols weren't exported, PAR broke, 
etc.) which is why 817 was pushed out of the door quickly. I don't 
*think* versions prior to build 816 were affected. Now, that doesn't 
help. It just means people who have AS Perl on their boxes since before 
the 816 release won't notice a problem. (Hence the cpan testers results 
for win32 are likely PASS if no other problems exist.) But if a new Perl 
programmer or an end user who wants to run an application written in 
Perl on Windows installs AS Perl build 817 (which happens to be 5.8.8), 
he or she will not be able to install many modules from CPAN. (One way 
or another you'll end up installing a M::I based module due to 
dependencies.)


Just one more thing. Please, nobody suggest that people download older 
AS Perl releases to fix this. It's not going to happen. Unless, of 
course, you want to limit the usage of Perl (and CPAN) to programmers 
and sysadmins.


Does that clarify things?

Steffen

Re: Old and broken versions of Module::Install

[Michael G Schwern]

On 7/6/06, Steffen Mueller <[EMAIL PROTECTED]> wrote:

Versions of Module::Install < 0.61 do not work on the current ActivePerl
release 5.8.8 build 817.


What's broken and why suddenly 5.8.8?

Re: Old and broken versions of Module::Install

[Chris Dolan]

On Jul 6, 2006, at 10:18 AM, A. Pagaltzis wrote:


* Chris Dolan <[EMAIL PROTECTED]> [2006-07-06 16:30]:

IMHO it likely counts as a CPANTS pass for now, but it may be a
fail in the future unless you update the Makefile.PL with a
newer M::B as bugs are discovered.


To make sure we’re on the same page: that would be bugs in
M::B::Compat, not M::B itself, right? If that isn’t accepted,
then I will revert to EU::MM (with apologies to Schwern) until
you all figure out the damn installers among yourselves.


Yes indeed, that's what I meant.  I'm not saying there are  
M::B::Compat bugs, just *if* any were discovered someday, they could  
be flagged by CPANTS.


Anywhere you have boilerplate code, you have the possibility of bugs  
that need to be fixed via the good intentions of authors deploying  
that boilerplate.  M::B- and EU::MM-using authors generally create  
minimal boilerplate and thus have a central point of upgrade.   
M::B::Compat is the only exception I could think of, so it became my  
example in my effort *not* to incite an M::I vs. M::B flamefest.   
Apologies for any confusion.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Old and broken versions of Module::Install

[A. Pagaltzis]

* Chris Dolan <[EMAIL PROTECTED]> [2006-07-06 16:30]:
> IMHO it likely counts as a CPANTS pass for now, but it may be a
> fail in the future unless you update the Makefile.PL with a
> newer M::B as bugs are discovered.

To make sure we’re on the same page: that would be bugs in
M::B::Compat, not M::B itself, right? If that isn’t accepted,
then I will revert to EU::MM (with apologies to Schwern) until
you all figure out the damn installers among yourselves.

But you’re not catching me dead using an installer that requires
me to pay attention to its development and to push up new
versions of my distros in response to its bugs. There are far
better ways to waste my time.

Sorry that this turned into an M::B/M::I flame anyway,
-- 
Aristotle Pagaltzis // 

Re: Old and broken versions of Module::Install

[A. Pagaltzis]

* Steffen Mueller <[EMAIL PROTECTED]> [2006-07-06 15:20]:
> What does Module::Build count as? ;)

I use M::B with `create_makefile_pl => 'traditional'`. What does
that count as?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Old and broken versions of Module::Install

[Chris Dolan]

On Jul 6, 2006, at 8:10 AM, Steffen Mueller wrote:


David Golden schrieb:

What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS?


Maybe tongue-in-cheek, but it's actually a good idea.  
Module::Install pre-0.61 is certainly "broken".


What does Module::Build count as? ;)

Steffen


I agree, this is a really good idea.  I would call it  
"UP_TO_DATE_INSTALLER".  For the present, it could simply test for  
old Module::Install.  In the future, it could be expanded to look for  
compatibility problems in Build.PL or Makefile.PL (e.g. a Makefile.PL  
using out-of-date Module::Build::Compat boilerplate).


If the CPANTS "game" gets any M::I-using authors to upgrade, then it  
has served its purpose.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Old and broken versions of Module::Install

[Chris Dolan]

On Jul 6, 2006, at 9:18 AM, A. Pagaltzis wrote:


* Steffen Mueller <[EMAIL PROTECTED]> [2006-07-06 15:20]:

What does Module::Build count as? ;)


I use M::B with `create_makefile_pl => 'traditional'`. What does
that count as?

Regards,
--  
Aristotle Pagaltzis // 


IMHO it likely counts as a CPANTS pass for now, but it may be a fail  
in the future unless you update the Makefile.PL with a newer M::B as  
bugs are discovered.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Old and broken versions of Module::Install

[Steffen Mueller]

David Golden schrieb:

What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS?


Maybe tongue-in-cheek, but it's actually a good idea. Module::Install 
pre-0.61 is certainly "broken".


What does Module::Build count as? ;)

Steffen

Re: Old and broken versions of Module::Install

[David Golden]

Steffen Mueller wrote:
Versions of Module::Install < 0.61 do not work on the current ActivePerl 
release 5.8.8 build 817. There are *a lot* of CPAN distributions that 
use Module::Install versions in the 0.3X range. In fact the most modules 
that use Module::Install are still 0.3X. For example an integral 
distribution like Scalar-List-Utils is using Module::Install 0.37. You 
can find a complete (and somewhat current) list of problematic modules 
at http://steffen-mueller.net/mi_old.html


Ideas?


What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS?

:-)

Regards,
David Golden

Old and broken versions of Module::Install

[Steffen Mueller]

Hi perl.qa,

hopefully, this message will not provoke another flame war about 
Module::Install and Module::Build. Please don't feel tempted. I don't 
care which build system you use if it works.


Versions of Module::Install < 0.61 do not work on the current ActivePerl 
release 5.8.8 build 817. There are *a lot* of CPAN distributions that 
use Module::Install versions in the 0.3X range. In fact the most modules 
that use Module::Install are still 0.3X. For example an integral 
distribution like Scalar-List-Utils is using Module::Install 0.37. You 
can find a complete (and somewhat current) list of problematic modules 
at http://steffen-mueller.net/mi_old.html


Installing modules from CPAN on win32 is really frustrating if you have 
to do the following dance for every other module you install:


(install current Module::Install once, then:)
> look Foo::Bar
$ rm -rf inc/
$ perl Makefile.PL
$ make
$ make install
$ exit

This is particularly nasty if it happens somewhere in the dependency chain.

Why am I posting here?

a) Perhaps some of those distributions belong to you. If so, please 
consider releasing a new version with a more current Module::Install or 
without using Module::Install at all.
b) You care about perl and CPAN qa. What can we do to motivate authors 
to upgrade?


Keep in mind that a kitten, err, a would-be win32 Perl programmer and/or 
user is turned away for every module that doesn't install because of 
this. In particular, the above solution for a module that doesn't 
install cleanly isn't known to just anybody because the error you get 
isn't self-explanatory.


Ideas?

Steffen