search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.85k stars 527 forks source link

Outdated Test::Harness::Straps #9180

Closed p5pRT closed 14 years ago

p5pRT commented 16 years ago

Migrated from rt.perl.org#49504 (status was 'resolved')

Searchable as RT49504$

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

Created by imacat@mail.imacat.idv.tw

Dear Perl people\,

  Hi. This is imacat from Taiwan. I'm running the newly-released Perl 5.10.0 now. I found that the version of Test​::Harness​::Straps that comes with Perl 5.10.0 is 0.26_01\, while the current version of Test​::Harness​::Straps is 0.29. It is in the updated modules list of the result of the CPAN shell "r" command (also CPANPLUS "o" command.)

  However\, Test​::Harness​::Straps does not install into the "perl" (core) section\, but into the site section. Since Test​::Harness​::Straps has ceased development\, not even bug fixes\, the above "dual-life" problem will never be fixed anymore. Then the installed new version will never be working (shadowed by the core version)\, and it is always in the updated modules list forever.

  Could you please supply the latest Test​::Harness​::Straps 0.29\, or remove it completely from the Perl core modules? Doing this will enable the "upgrade" command of the CPAN shell working as normal again.

  Please tell me if you need any information\, or if I could be of any help. Thank you.

Perl Info ``` Flags: category=library severity=medium Site configuration information for perl 5.10.0: Configured by imacat at Thu Dec 27 12:57:27 CST 2007. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=linux, osvers=2.6.22.10, archname=x86_64-linux-thread-multi-ld uname='linux rinse 2.6.22.10 #1 smp tue nov 20 02:36:22 cst 2007 x86_64 gnulinux ' config_args='-d -Dusethreads -Dcc=gcc -Duselongdouble -Doptimize=-g -O3 -Duse64bitint -Duse64bitall -Dprefix=/opt/perl/5.10.0 -Dd_dosuid -Dinc_version_list=none -Duseshrplib=true -Dcf_email=imacat@mail.imacat.idv.tw' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g -O3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-21)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=16, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.6' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/opt/perl/5.10.0/lib/5.10.0/x86_64-linux-thread-multi-ld/CORE' cccdlflags='-fPIC', lddlflags='-shared -g -O3 -L/usr/local/lib' Locally applied patches: @INC for perl 5.10.0: /home/imacat/lib/perl5 /opt/perl/5.10.0/lib/5.10.0/x86_64-linux-thread-multi-ld /opt/perl/5.10.0/lib/5.10.0 /opt/perl/5.10.0/lib/site_perl/5.10.0/x86_64-linux-thread-multi-ld /opt/perl/5.10.0/lib/site_perl/5.10.0 . Environment for perl 5.10.0: HOME=/home/imacat LANG=zh_TW LANGUAGE=zh_TW LC_ALL=zh_TW LC_COLLATE=zh_TW LC_CTYPE=zh_TW LC_MESSAGES=zh_TW LC_MONETARY=zh_TW LC_NUMERIC=zh_TW LC_TIME=zh_TW LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/imacat/bin:/bin:/usr/bin:/opt/java/bin:/usr/local/bin PERL5LIB=/home/imacat/lib/perl5 PERL_BADLANG (unset) SHELL=/bin/zsh ```
p5pRT commented 16 years ago

From @schwern

imacat@​mail.imacat.idv.tw (via RT) wrote​:

Hi\.  This is imacat from Taiwan\.  I'm running the newly\-released

Perl 5.10.0 now. I found that the version of Test​::Harness​::Straps that comes with Perl 5.10.0 is 0.26_01\, while the current version of Test​::Harness​::Straps is 0.29. It is in the updated modules list of the result of the CPAN shell "r" command (also CPANPLUS "o" command.)

However\, Test​::Harness​::Straps does not install into the "perl"

(core) section\, but into the site section. Since Test​::Harness​::Straps has ceased development\, not even bug fixes\, the above "dual-life" problem will never be fixed anymore.

Well I can certainly put in an "installdirs => 'core'". That was just an oversight. "No bugs will be fixed" applies to the code\, I just don't want to be doing Straps bug fixes when TAP​::Parser is around.

A new version has been uploaderated.

(I see the Test-Harness-Straps bug queue is empty. Even if you don't think the author won't fix it\, it never hurts to report it.)

-- But there's no sense crying over every mistake. You just keep on trying till you run out of cake.   -- Jonathan Coulton\, "Still Alive"

p5pRT commented 16 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Tue\, 08 Jan 2008 14​:37​:36 -0800 "Michael G Schwern via RT" \perlbug\-followup@​perl\.org wrote​:

imacat@​mail.imacat.idv.tw (via RT) wrote​: Well I can certainly put in an "installdirs => 'core'". That was just an oversight. "No bugs will be fixed" applies to the code\, I just don't want to be doing Straps bug fixes when TAP​::Parser is around.

  Well\, sorry\, and thanks. ^_*' But I think "No bugs will be fixed" will certainly scare away people from reporting the issue. At least it works for me. ^^;

  By the way\, could you please also add the attached Makefile.PL into Test-Harness-Straps? This is the ExtUtils​::MakeMaker equivalent of your Build.PL. Perl 5.8.8 does not come with Module​::Build\, and a CPAN shell on a clean Perl 5.8.8 cannot run "upgrade" cleanly with Test-Harness-Straps\, too. Thank you very much for this.

-- Best regards\, imacat ^_*' \imacat@​mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

Makefile.PL

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

On Tue\, 08 Jan 2008 14​:37​:36 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat@​mail.imacat.idv.tw (via RT) wrote​: Well I can certainly put in an "installdirs => 'core'". That was just an oversight. "No bugs will be fixed" applies to the code\, I just don't want to be doing Straps bug fixes when TAP​::Parser is around.

Well\, sorry\, and thanks\. ^\_\*'  But I think "No bugs will be fixed"

will certainly scare away people from reporting the issue. At least it works for me. ^^;

By the way\, could you please also add the attached Makefile\.PL into

Test-Harness-Straps? This is the ExtUtils​::MakeMaker equivalent of your Build.PL. Perl 5.8.8 does not come with Module​::Build\, and a CPAN shell on a clean Perl 5.8.8 cannot run "upgrade" cleanly with Test-Harness-Straps\, too. Thank you very much for this.

That is a bug in the CPAN shell and should be fixed. I'm already aware that CPANPLUS has this problem and am working on a fix along two lines. http​://rt.cpan.org/Ticket/Display.html?id=31279 http​://rt.cpan.org/Ticket/Display.html?id=29676

Everyone's hacking around it\, I'd rather fix it. It's embarrassing that the shiny new CPAN shell and the shiny new build system don't work together. So for this one I have to say sorry\, won't fix\, but I will push it upstream. :)

CPAN.pm\, however\, should detect the Build.PL and install Module​::Build for you. Is this not working or were you referring to CPANPLUS?

-- If at first you don't succeed--you fail.   -- "Portal" demo

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Wed\, 09 Jan 2008 16​:05​:04 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​:

On Tue\, 08 Jan 2008 14​:37​:36 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​: That is a bug in the CPAN shell and should be fixed. I'm already aware that CPANPLUS has this problem and am working on a fix along two lines. http​://rt.cpan.org/Ticket/Display.html?id=31279 http​://rt.cpan.org/Ticket/Display.html?id=29676 Everyone's hacking around it\, I'd rather fix it. It's embarrassing that the shiny new CPAN shell and the shiny new build system don't work together. So for this one I have to say sorry\, won't fix\, but I will push it upstream. :)

  Well... I am a little confused. I do not see the reason that stops you from shipping an equivalent Makefile.PL. This is really a small thing. This Build.PL does not use Module​::Build special functions\, and an equivalent Makefile.PL is easy to generate\, and is already there. For this reason I have to install Module​::Build only to meet the dependency of the "upgrade" command in my 5.8.8.

  I suppose you like Module​::Build. But please understand\, too\, that some people simply like ExtUtils​::MakeMaker\, and some people simply do not like to install extra dmodules that are used only once\, like me.

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

On Wed\, 09 Jan 2008 16​:05​:04 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​:

On Tue\, 08 Jan 2008 14​:37​:36 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​: That is a bug in the CPAN shell and should be fixed. I'm already aware that CPANPLUS has this problem and am working on a fix along two lines. http​://rt.cpan.org/Ticket/Display.html?id=31279 http​://rt.cpan.org/Ticket/Display.html?id=29676 Everyone's hacking around it\, I'd rather fix it. It's embarrassing that the shiny new CPAN shell and the shiny new build system don't work together. So for this one I have to say sorry\, won't fix\, but I will push it upstream. :)

Well\.\.\. I am a little confused\.  I do not see the reason that stops

you from shipping an equivalent Makefile.PL. This is really a small thing.

For the same reasons you won't just install Module​::Build on your smoke testing boxes. This isn't about the immediate issue of getting Test​::Harness​::Straps installed. We both want to find problems and shine spotlights on them. Rather than paper over problems\, we'll drive everyone crazy until they get fixed. [1] :)

This Build.PL does not use Module​::Build special functions\, and an equivalent Makefile.PL is easy to generate\, and is already there.

Sure\, easy\, unless you're the guy who has to write and maintain that compatibility stuff and the underlying MakeMaker. I've already put far more effort into what should have been a TEMPORARY EMULATOR to help people transition. It's not a universal translator\, but people are treating it as such sucking away more of my time.

I suppose you like Module&#8203;::Build\.  But please understand\, too\, that

some people simply like ExtUtils​::MakeMaker

Some people might like Test.pm\, doesn't mean I'm going to provide a compatibility wrapper for my tests so they don't have to install Test​::More [2] or that it matters one wit what the user prefers because it should all be automated with user preferences having nothing to do with it.

We don't systematically apply "user preferences" to any other module dependency. If Some​::Module depends on Another​::Module it doesn't matter how many interpretive dances one does to express their feelings about that\, the dependency remains and the code won't work without it.

Finally\, I hate MakeMaker. And if anyone's personal feelings are going to be taken into consideration here it's the guy who's actually coding MakeMaker and maintaining the THS distribution. My hate trumps your like. (ha ha\, only serious)

and some people simply do not like to install extra dmodules that are used only once\, like me.

Hmm? How is it used only once?

[1] The person being driven crazy to fix it may well be me\, and that's fine. [2] Yes\, I realize they're both core but it wasn't always that way.

PS This diatribe was leveled less towards you personally and more towards the "I don't want to use Module​::Build" issue.

-- Reality is that which\, when you stop believing in it\, doesn't go away.   -- Phillip K. Dick

p5pRT commented 16 years ago

From @andk

On Wed\, 09 Jan 2008 16​:04​:16 -0800\, Michael G Schwern \schwern@&#8203;pobox\.com said​:

By the way\, could you please also add the attached Makefile.PL into Test-Harness-Straps? This is the ExtUtils​::MakeMaker equivalent of your Build.PL. Perl 5.8.8 does not come with Module​::Build\, and a CPAN shell on a clean Perl 5.8.8 cannot run "upgrade" cleanly with Test-Harness-Straps\, too. Thank you very much for this.

  > That is a bug in the CPAN shell and should be fixed.

Imacat is right. You cannot fix a bug in released perl tarballs. The bug is fixed in CPAN.pm but not in the versions in 5.8.8 and before. I see it as a matter of politeness to support TIMTOWTDI for users of 5.8.8 (and before) where it does not cost you any effort.

-- andreas

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Thu\, 10 Jan 2008 18​:22​:06 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​: For the same reasons you won't just install Module​::Build on your smoke testing boxes. This isn't about the immediate issue of getting Test​::Harness​::Straps installed. We both want to find problems and shine spotlights on them. Rather than paper over problems\, we'll drive everyone crazy until they get fixed. [1] :)

  The reason is easy​: Forgetting to set prerequisites is a bug that is hard to catch. I myself made this mistake once\, and I found that this is quite common among Perl authors. To avoid this I intend to install as less modules as possible.

Sure\, easy\, unless you're the guy who has to write and maintain that compatibility stuff and the underlying MakeMaker. I've already put far more

  If you are talking about this\, well\, as my plan B\, I was planning to suggest if you do not want to maintain it anymore\, may I take over it\, in order to solve some issues I observed? I shall follow the principle that this package/module is going to be retired. As something that won't have bug fixes\, it does not matter if I understand the code or not. This way it won't drain your precious time and effort.

PS This diatribe was leveled less towards you personally and more towards the "I don't want to use Module​::Build" issue.

  There seems to be public rumors that\, I\, imacat\, don't want to use Module​::Build.

  You can take back your words if you see this​:

http​://search.cpan.org/dist/Locale-Maketext-Gettext/

  As a Perl user posted 50+ bugs in rt.cpan.org and sent 20000+ CPAN tester reports\, I was always accused of all kinds of things from various Perl authors​: My self-built kernel\, my environment has problem\, I don't want to use Module​::Build\, ... etc.. The only reason I do this is that I believe in field testing\, that is\, a quality package should work on all kinds of environment it will encounter\, and user environment is not an excuse of software failure. Besides this\, everything else is purely imagination and non-sense flamewar.

-- imacat ^_*' imacat@​mail.imacat.idv.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

Tavern IMACAT's http​://www.imacat.idv.tw/ Woman's Voice http​://www.wov.idv.tw/ TLUG List Manager http​://www.linux.org.tw/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @ap

* imacat \imacat@&#8203;mail\.imacat\.idv\.tw [2008-01-14 16​:45]​:

As a Perl user posted 50+ bugs in rt.cpan.org and sent 20000+ CPAN tester reports\, I was always accused of all kinds of things from various Perl authors​: My self-built kernel\, my environment has problem\, I don't want to use Module​::Build\, ... etc.. The only reason I do this is that I believe in field testing\, that is\, a quality package should work on all kinds of environment it will encounter\, and user environment is not an excuse of software failure. Besides this\, everything else is purely imagination and non-sense flamewar.

++

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

p5pRT commented 16 years ago

From publiustemp-p5p3@yahoo.com

--- imacat \imacat@&#8203;mail\.imacat\.idv\.tw wrote​:

As a Perl user posted 50\+ bugs in rt\.cpan\.org and sent 20000\+

CPAN tester reports\, I was always accused of all kinds of things from various Perl authors​: My self-built kernel\, my environment has problem\, I don't want to use Module​::Build\, ... etc.. The only reason I do this is that I believe in field testing\, that is\, a quality package should work on all kinds of environment it will encounter\, and user environment is not an excuse of software failure. Besides this\, everything else is purely imagination and non-sense flamewar.

For what it's worth\, I've been quite grateful for you and your work. I thank you and hope you keep up the great work.

I find it sad that so many companies have this tension between QA and developers and here were are\, seeing the EXACT same thing.

Cheers\, Ovid

-- Buy the book - http​://www.oreilly.com/catalog/perlhks/ Perl and CGI - http​://users.easystreet.com/ovid/cgi_course/ Personal blog - http​://publius-ovidius.livejournal.com/ Tech blog - http​://use.perl.org/~Ovid/journal/

p5pRT commented 16 years ago

From @JohnPeacock

imacat wrote​:

As a Perl user posted 50\+ bugs in rt\.cpan\.org and sent 20000\+ CPAN

tester reports\, I was always accused of all kinds of things from various Perl authors​: My self-built kernel\, my environment has problem\, I don't want to use Module​::Build\, ... etc.. The only reason I do this is that I believe in field testing\, that is\, a quality package should work on all kinds of environment it will encounter\, and user environment is not an excuse of software failure. Besides this\, everything else is purely imagination and non-sense flamewar.

I have avoided taking part in this discussion\, because I too have had a bad experience with imacat's "testing methodology". I am all in favor of testing; I have several modules that I'm sure that lots of people would find useful that are unreleased because I don't have any way of providing a portable testing framework (Net​::SMTP​::ESMTP for one). I have pushed the envelope with version objects back to 5.004 through the use of testing. The "home page" for my browser at home is the JPEACOCK page on testers.cpan.org. I get it.

With all that being said\, imacat has some very specific ideas about "whitebox testing" which are\, in my not so humble opinion\, completely whack. Most of the discussion I had on this topic appears in this ticket​:

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

You can also see the discussion on the Module​::Build list archives starting here​:

  http​://www.nntp.perl.org/group/perl.module.build/2007/05/msg689.html

Note carefully that imacat thinks I must provide a fully functional Makefile.PL\, not because there is anything wrong with the Build.PL I provide\, but because imacat's own system can't handle installing Module​::Build. And the reason that it cannot handle installing Module​::Build is because none of the "infrastructure" modules have been updated (e.g. EU​::MM or CPAN) to newer versions.

There is a valid reason to perform competely 'tabula rasa' testing\, where the only things installed are the base packages. It's for testing upgrading the infrastructure modules themselves (see above). But this sort of testing is not representative of the real world\, where the first thing someone installing via a newly installed Perl is the CPAN message urging them to upgrade to the current release. A release\, by the way\, that handles Build.PL just fine\, thanks.

imacat explicitly wants me to change the dependency graph of my module because it messes up automated testing on *one* machine. This isn't a flamewar\, because I *don't* *care* that imacat can't test my modules anymore. I don't believe that the style of testing that imacat is advocating has much use in the real world.

My final words on the subject.

John

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Tue\, 15 Jan 2008 04​:43​:42 -0800 "John Peacock via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​: With all that being said\, imacat has some very specific ideas about "whitebox testing" which are\, in my not so humble opinion\, completely whack. Most of the discussion I had on this topic appears in this ticket​:

  This is off-topic\, and I was not ready for this issue yet. But since you raised it\, it maybe a good chance for this.

  Some (not all) Module​::Build users supply a Makefile.PL that​:

  (a) Raise a CPAN shell that install Module​::Build.   (b) Use Module​::Build to install itself.

  There are 2 problems with this setting. For a non-root user that want to install to their home directory\, having their CPAN shell with​:

makepl_arg => "INSTALLDIRS=/home/jenny/perl" mbuild_arg => "installdirs=/home/jenny/perl" (or for CPANPLUS\, makemakerflags => "INSTALLDIRS=/home/jenny/perl" buildflags => "installdirs=/home/jenny/perl")

  1. The (a) won't work. The raised CPAN shell does not get the INSTALLDIRS or installdirs. It will try to install into the system library directories and fail. In that case\, that strange Makefile.PL will enter an endless loop retrying to install Module​::Build again and again.

  2. The (b) won't work\, too. Module​::Build does not obtain "installdirs=/home/jenny/perl"\, but "INSTALLDIRS=/home/jenny/perl". It will try to install into the system library directories and fail\, too.

  As far as I know\, the CPAN and CPANPLUS shells both assume Makefile.PL is for ExtUtils​::MakeMaker\, and Build.PL is for Module​::Build. Therefore\, providing Makefile.PL that runs Module​::Build but not ExtUtils​::MakeMaker should be considered a mistake.

  However\, there seems to be a lot of authors supplying that same Makefile.PL. I do not know why. As what I read from the Module​::Build documentation\, though little\, I did not see such suggestion anywhere. If someone can point out the source of such Makefile.PL\, maybe this issue can be solved in a more efficient way.

  When I proposed this problem\, in a primitive way that "CPAN testing enters an infinite loop" as I did not understand this problem quite well at that time\, I was accused of "I don't like to install Module​::Build." or some white box thing\, on some discussion threads that I'm not participating.

  I suppose it's not a good thing to talk behind someone\, but obviously some people do not care. All the discussion on that Makefile.PL seems to exclude me\, and obtain several conclusions about me all by themselves. This gives me a feeling that part of the Module​::Build user group is not fair\, though this is not important.

  Sorry for this is off-topic. I still thank that many Perl authors and Module​::Build users are polite and response positively with bug reports. It's not easy for people to smile to someone that point out your mistakes on your face\, and this includes me.

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @ap

* imacat \imacat@&#8203;mail\.imacat\.idv\.tw [2008-01-15 20​:40]​:

If someone can point out the source of such Makefile.PL\, maybe this issue can be solved in a more efficient way.

http​://search.cpan.org/perldoc?Module​::Build​::Compat#passthrough

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

p5pRT commented 16 years ago

From @andk

On Tue\, 15 Jan 2008 07​:43​:15 -0500\, John Peacock \john\.peacock@&#8203;havurah\-software\.org said​:

  > There is a valid reason to perform competely 'tabula rasa'   > testing\, where the only things installed are the base packages.

Yes!

  > It's for testing upgrading the infrastructure modules themselves

More important than that\, this is how perl presents itself to every new user.

  > But this sort of testing is not representative of the real world\,

On the contrary! Everybody except those familiar with the language necessarily has to approach perl from the tabula rasa point of view.

  > where the first thing someone installing via a newly installed   > Perl is the CPAN message urging them to upgrade to the current   > release.

I don't think it's arguable that everybody who comes to perl is eagerly awaiting to fire the CPAN shell as the first thing to do.

-- andreas

p5pRT commented 16 years ago

From @JohnPeacock

Andreas J. Koenig wrote​:

On Tue\, 15 Jan 2008 07​:43​:15 -0500\, John Peacock \john\.peacock@&#8203;havurah\-software\.org said​: where the first thing someone installing via a newly installed Perl is the CPAN message urging them to upgrade to the current release.

I don't think it's arguable that everybody who comes to perl is eagerly awaiting to fire the CPAN shell as the first thing to do.

But we are talking about modules distributed via CPAN\, which sort of implies that the user is already running CPAN/CPANPLUS or at the very least has downloaded a tarball from the CPAN website. This already implies that the user has passed beyond merely using Perl for simple tasks\, but is potentially writing code that depends on other people's modules.

My target audience is _users_ of my modules\, *not* the automated CPAN testing hordes. Hence\, any deviation by the testing framework from how an ordinary user would perceive the installation process doesn't show any weakness in my installation process\, but rather a weakness in the testing framework. I'm not able to fix that\, since it isn't my code.

An ordinary user using either CPAN\, CPANPLUS\, or just a tarball\, can install SVN​::Notify​::Mirror (the module that imacat complained about) just fine\, without even having to upgrade CPAN even. If they don't have Module​::Build installed\, the compatibility Makefile.PL will offer to install it for them\, with the default answer being Y\, since we can safely imply that they did\, in fact\, intend to install my module and hence require my dependencies first. That is\, in fact\, the whole reason for the compatibility Makefile.PL!

If there is a problem installing Module​::Build automatically within the testing framework\, but not as an ordinary user\, then the fault lies with the testing framework itself\, not the build process involved. As near as I can tell\, (based on the /true/ failure reports against this module)\, every reported failure was on a box with *some* version of Module​::Build installed (thus obviating imacat's looping problem). imacat refuses to do this\, because it would violate the constraints of "true whitebox" testing\, even though it is the automated test framework itself that is having the problem.

I'm not removing the compatibility Makefile.PL (and I know there are other CPAN authors who feel this way) because it specifically helps *real* users bootstrap the toolchain I have chosen to use. I am not changing my toolchain\, or providing a "true" EU​::MM Makfile.PL because I can easily do things with M​::B that would be a real pain with EU​::MM.

I'm also not going to use Module​::Install (which bundles the dependencies) because\, notwithstanding Adams et al's very good intentions\, it replicates many of the warts of EU​::MM and doesn't even cover the entire EU​::MM interface properly. Plus\, anytime M​::I releases a bugfix\, I would have to roll new distributions of my own modules\, even if my module didn't change. If that wasn't bad enough\, there have been problems for *authors* who have M​::I installed interfering with installs of modules with a differing version of M​::I (I don't know if this is fixed now\, the ticket I opened a year ago is still open).

In short\, the compatibility Makefile.PL assists the ordinary user. If it breaks the test framework\, that is outside of my ability to fix. If there is a workaround (like installing Module​::Build on the test box)\, then it is 100% imacat's problem that the compatibility Makefile.PL will loop. Not mine. There isn't anything I can fix here.

John

p5pRT commented 16 years ago

From @JohnPeacock

imacat wrote​:

This is off\-topic\, and I was not ready for this issue yet\.  But

since you raised it\, it maybe a good chance for this.

This will be brief.

There are 2 problems with this setting\.  For a non\-root user that

want to install to their home directory\, having their CPAN shell with​:

makepl_arg => "INSTALLDIRS=/home/jenny/perl" mbuild_arg => "installdirs=/home/jenny/perl" (or for CPANPLUS\, makemakerflags => "INSTALLDIRS=/home/jenny/perl" buildflags => "installdirs=/home/jenny/perl")

 1\. The \(a\) won't work\.  The raised CPAN shell does not get the

INSTALLDIRS or installdirs.

This is a problem with CPAN. File a bug there and leave my module out of it. I also think you are mistaken\, since I use that feature at $WORK to build a custom RPM of many CPAN modules.

 2\. The \(b\) won't work\, too\.  Module&#8203;::Build does not obtain

"installdirs=/home/jenny/perl"\, but "INSTALLDIRS=/home/jenny/perl". It will try to install into the system library directories and fail\, too.

This was a bug in Module​::Build​:

Revision history for Perl extension Module​::Build.

- Fixed processing of INSTALLDIRS=whatever for compatibility Makefiles. [Spotted by John Peacock]

This code needs to get released to CPAN\, but it is included in bleadperl.

John

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

Dear Michael G Schwern\,

On Thu\, 10 Jan 2008 18​:20​:53 -0800 Michael G Schwern \schwern@&#8203;pobox\.com wrote​:

imacat wrote​: Sure\, easy\, unless you're the guy who has to write and maintain that compatibility stuff and the underlying MakeMaker. I've already put far more

  In that case\, could you please apply this patch to the Test-Harness-Straps? It's only one line\, and you don't have to maintain the compatibility at all and will drain no time and energy.

-----BEGIN PGP SIGNED MESSAGE----- Hash​: SHA1

diff -u -r Test-Harness-Straps-0.30.orig/Build.PL Test-Harness-Straps-0.30/Build.PL - --- Test-Harness-Straps-0.30.orig/Build.PL 2008-01-09 06​:34​:35.000000000 +0800 +++ Test-Harness-Straps-0.30/Build.PL 2008-01-17 02​:28​:36.000000000 +0800 @​@​ -21\,5 +21\,6 @​@​   dist_author => 'Michael G Schwern \schwern@&#8203;pobox\.com'\,  
  installdirs => 'core'\, + create_makefile_pl => 'traditional'\, ); $build->create_build_script; -----BEGIN PGP SIGNATURE----- Version​: GnuPG v1.4.8 (GNU/Linux)

iEYEARECAAYFAkeOTOsACgkQi9gubzC5S1x+JACbBCFRRVatsuBiytqBkoukHqO3 rN8An26OW8lHyqAOdvWHdBShU2QaVaIa =YsYB -----END PGP SIGNATURE-----

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Wed\, 16 Jan 2008 07​:33​:25 -0500 John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

imacat wrote​:

 1\. The \(a\) won't work\.  The raised CPAN shell does not get the

INSTALLDIRS or installdirs. This is a problem with CPAN. File a bug there and leave my module out of it. I also think you are mistaken\, since I use that feature at $WORK to build a custom RPM of many CPAN modules.

  I do not think this is a problem of the CPAN or CPANPLUS shell. That "passthrough" Makefile.PL raised a new CPAN shell all by itself\, which by nature will not inherit the current configuration of the parent shell (if exists). For example\, if someone set makepl_arg or makemakerflags in this current CPAN shell session only\, to install to a specific directory only for now\, the newly-reised subshell will never know it since they are seperate processes.

  Also\, as I know\, the Makefile.PL of Module​::Build is running itself (Module​::Build) to install itself. It naturally does not understand PREFIX or INSTALLDIRS or everything in makepl_arg or makemakerflags that is passed to it\, even if there is any.

 2\. The \(b\) won't work\, too\.  Module&#8203;::Build does not obtain

"installdirs=/home/jenny/perl"\, but "INSTALLDIRS=/home/jenny/perl". It will try to install into the system library directories and fail\, too. Revision history for Perl extension Module​::Build. - Fixed processing of INSTALLDIRS=whatever for compatibility Makefiles. [Spotted by John Peacock] This code needs to get released to CPAN\, but it is included in bleadperl.

  Wait\, you are solving it in a wrong way.

  INSTALLDIRS is only an example. I may not make it very clear. People may set makepl_arg (or makemakerflags) to anything and expect ExtUtils​::MakeMaker to deal with it. Unless Module​::Build is going to accept all ExtUtils​::MakeMaker arguments for compatibility\, this is a wrong direction.

  And\, as my typo\, for ExtUtils it should be PREFIX\, as --prefix in Module​::Build. But\, then\, you have to build a full map and accept everything ExtUtils​::MakeMaker and convert it into Module​::Build. That is really crazy. As what I understand\, several of their arguments does not have a corresponding. Such a argument map does not exist.

  That "passthrough" is itself not right. No user-preferred Module​::Build arguments\, either mbuild_arg or buildflags\, will get passed to Makefile.PL under either CPAN or CPANPLUS shell.

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From scratchcomputing@gmail.com

# from imacat # on Wednesday 16 January 2008 10​:55​:

    That "passthrough" is itself not right.  No user-preferred Module​::Build arguments\, either mbuild_arg or buildflags\, will get passed to Makefile.PL under either CPAN or CPANPLUS shell.

If the user defined these arguments\, why are they running Makefile.PL?

--Eric -- The only thing that could save UNIX at this late date would be a new $30 shareware version that runs on an unexpanded Commodore 64. --Don Lancaster (1991)

  http​://scratchcomputing.com

p5pRT commented 16 years ago

From @ap

* Eric Wilhelm \scratchcomputing@&#8203;gmail\.com [2008-01-17 02​:05]​:

# from imacat # on Wednesday 16 January 2008 10​:55​:

That "passthrough" is itself not right.  No user-preferred Module​::Build arguments\, either mbuild_arg or buildflags\, will get passed to Makefile.PL under either CPAN or CPANPLUS shell.

If the user defined these arguments\, why are they running Makefile.PL?

Because that’s what the CPAN shell runs by default when it finds one.

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

p5pRT commented 16 years ago

From @tux

On Thu\, 17 Jan 2008 13​:44​:55 +0100\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.de wrote​:

* Eric Wilhelm \scratchcomputing@&#8203;gmail\.com [2008-01-17 02​:05]​:

# from imacat # on Wednesday 16 January 2008 10​:55​:

That "passthrough" is itself not right.  No user-preferred Module​::Build arguments\, either mbuild_arg or buildflags\, will get passed to Makefile.PL under either CPAN or CPANPLUS shell.

If the user defined these arguments\, why are they running Makefile.PL?

Because that’s what the CPAN shell runs by default when it finds one.

not only when using the CPAN shell.

I just used a module that does NOT have a Makefile.PL :( To be fair\, it was not yet released to CPAN\, but still\, what happened​:

# tar xzf Module-0.00.tgz # cd Module-0.00 # perl Makefile.PL

... curse

# ls # perl Build.PL # make

... curse

# Build # make test

... curse

# Build test # Build install UNINST=1

By this time I really hated Module​::Build\, even if it acts exactly as it should.

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test'

Too simplistic?

-- H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/) using & porting perl 5.6.2\, 5.8.x\, 5.10.x on HP-UX 10.20\, 11.00\, 11.11\, & 11.23\, SuSE 10.1 & 10.2\, AIX 5.2\, and Cygwin. http​://qa.perl.org http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org   http​://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 16 years ago

From @ap

* H.Merijn Brand \h\.m\.brand@&#8203;xs4all\.nl [2008-01-17 14​:10]​:

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test'

Too simplistic?

Harmful. Default CPAN config is to use Makefile.PL when present\, so if that croaks without even attempting to install\, then the module it becomes uninstallable for a great number of users.

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

p5pRT commented 16 years ago

From @JohnPeacock

H.Merijn Brand wrote​:

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test'

If you ever stepped away from your *nix box\, you might know the answer to that question. Module​::Build does not require make/nmake/mmk at all (it is really one of the key points of its design). There is no reason to blindly create a Makefile for the few hardcore people who can't be bothered to look at the README file\, which it least in my case always say something like​:

INSTALLATION   Install Module​::Build and then run​:

  $ perl Build.PL   $ ./Build   $ ./Build test   $ su   # ./Build install

It's not my job to cater to your laziness... ;-)

John

p5pRT commented 16 years ago

From @tux

On Thu\, 17 Jan 2008 09​:18​:25 -0500\, John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

H.Merijn Brand wrote​:

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test'

If you ever stepped away from your *nix box\, you might know the answer

Same with Cygwin and strawberry. Neither of those are *nix (though Cygwin claims to be as close as possible)

to that question. Module​::Build does not require make/nmake/mmk at all

I know

(it is really one of the key points of its design). There is no reason to blindly create a Makefile for the few hardcore people who can't be

a few?

bothered to look at the README file\, which it least in my case always say something like​:

INSTALLATION Install Module​::Build and then run​:

 $ perl Build\.PL
 $ \./Build
 $ \./Build test
 $ su
 \# \./Build install

OK\, maybe not fair\, because it is not (yet) on CPAN\, but lemme summarize (real names obfuscated for protecting the innocent)

% cat README NAME   Foo​::Bar - Support Bar for Foo

DESCRIPTION   This module is part of the beta Foo project.   http​://foo.bar.org

AUTHOR   Autor\, \AUTHOR@&#8203;cpan\.org

LICENSE   This code is distributed under the same license as Perl.

% ls bin Changelog lib MANIFEST.SKIP README TODO Build.PL Changes MANIFEST META.yml t %

No info in README and no INSTALL file. Were am I supposed to look next? FWIW\, neither is `fixing' this mentioned in the TODO

It's not my job to cater to your laziness... ;-)

Laziness is one of my virtues.

-- H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/) using & porting perl 5.6.2\, 5.8.x\, 5.10.x on HP-UX 10.20\, 11.00\, 11.11\, & 11.23\, SuSE 10.1 & 10.2\, AIX 5.2\, and Cygwin. http​://qa.perl.org http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org   http​://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 16 years ago

From @tux

On Thu\, 17 Jan 2008 15​:35​:18 +0100\, "H.Merijn Brand" \h\.m\.brand@&#8203;xs4all\.nl wrote​:

On Thu\, 17 Jan 2008 09​:18​:25 -0500\, John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

OK\, maybe not fair\, because it is not (yet) on CPAN\, but lemme summarize (real names obfuscated for protecting the innocent)

I've just checked on previous version of this module that were already released on CPAN\, and they indeed do have an auto-generated Makefile.PL that actually works fine.

Just to be fair.

It's not my job to cater to your laziness... ;-)

Laziness is one of my virtues.

-- H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/) using & porting perl 5.6.2\, 5.8.x\, 5.10.x on HP-UX 10.20\, 11.00\, 11.11\, & 11.23\, SuSE 10.1 & 10.2\, AIX 5.2\, and Cygwin. http​://qa.perl.org http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org   http​://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

Dear Michael G Schwern\,

On Thu\, 10 Jan 2008 18​:20​:53 -0800 Michael G Schwern \schwern@&#8203;pobox\.com wrote​:

imacat wrote​: Sure\, easy\, unless you're the guy who has to write and maintain that compatibility stuff and the underlying MakeMaker. I've already put far more

In that case\, could you please apply this patch to the

Test-Harness-Straps? It's only one line\, and you don't have to maintain the compatibility at all and will drain no time and energy.

Sorry\, holding firm on this one. It's not a maintenance issue\, it would be considerably less effort at this point to just put it in. I want to see what a pure Module​::Build dist breaks and make sure it gets fixed.

As for the issue of being able to install it from a stock 5.8.8\, this is not a critical distribution at all. It's only there in case someone upgrades to Test​::Harness 3 and still needs Straps. 5.8.8 already has Straps\, so it's not likely to be an issue until 5.10.1 which will handle Build.PL out of the box just fine.

Don't let the 0.30 vs 0.26 in 5.8.8 fool you\, those are all just distribution changes\, not code. In fact\, the 5.8.8 version is slightly newer but was never released to CPAN.

Only if you're a compulsive upgrader would you install this\, which means you've probably updated your toolchain as well.

Again\, sorry for the inconvenience.

diff -u -r Test-Harness-Straps-0.30.orig/Build.PL Test-Harness-Straps-0.30/Build.PL --- Test-Harness-Straps-0.30.orig/Build.PL 2008-01-09 06​:34​:35.000000000 +0800 +++ Test-Harness-Straps-0.30/Build.PL 2008-01-17 02​:28​:36.000000000 +0800 @​@​ -21\,5 +21\,6 @​@​ dist_author => 'Michael G Schwern \schwern@&#8203;pobox\.com'\,

 installdirs     => 'core'\,

+ create_makefile_pl => 'traditional'\, ); $build->create_build_script;

-- 87. If the thought of something makes me giggle for longer than 15   seconds\, I am to assume that I am not allowed to do it.   -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army   http​://skippyslist.com/?page_id=3

p5pRT commented 16 years ago

From @schwern

H.Merijn Brand wrote​:

% ls bin Changelog lib MANIFEST.SKIP README TODO Build.PL Changes MANIFEST META.yml t %

No info in README and no INSTALL file. Were am I supposed to look next? FWIW\, neither is `fixing' this mentioned in the TODO

That's a valid concern. There are provisions in Module​::Build to automatically generate a README\, create_readme()\, but it's of the "spit out the POD" variety that just parrots the module documentation.

What is needed is an associated create_install() that contains installation instructions. It's pretty much a SMOP\, and just Perl not make and shell so anybody should be able to do it. Here's the outline. http​://rt.cpan.org//Ticket/Display.html?id=32391

-- 60. “The Giant Space Ants” are not at the top of my chain of command.   -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army   http​://skippyslist.com/?page_id=3

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

This is off\-topic\, and I was not ready for this issue yet\.  But

since you raised it\, it maybe a good chance for this.

Some \(not all\) Module&#8203;::Build users supply a Makefile\.PL that&#8203;:

 \(a\) Raise a CPAN shell that install Module&#8203;::Build\.
 \(b\) Use Module&#8203;::Build to install itself\.

There are 2 problems with this setting\.

**--problems with running a compatibility Makefile.PL snipped--**

Problems of this nature is why both the MakeMaker maintainers and the Module​::Build maintainers have been saying for YEARS to prefer the Build.PL. Emulation sucks and always will.

CPAN.pm has preferred Module​::Build since 1.92\, but it will not overwrite an existing configuration. CPANPLUS is in the middle of improving their Module​::Build support and will switch their preference to MB when that's done.   My thanks to both Jos and Andreas for that work.

Specifically\, the infinite loop generating compatibility Makefile.PLs were from before Module​::Build generated its own cut and pasted from an old Module​::Build perl.com article. I believe that problem has long since been corrected in the Module​::Build​::Compat generated "passthrough" Makefile.PLs. A handful of distributions still contain that old Makefile.PL\, or authors stumble on that old article and cut & paste the code\, but that's code generation for ya and should be considered a bug in that distribution.

But I stand by my statement​: Emulation sucks. Don't use it if you don't have to. It causes all sorts of fascinating and expensive problems.

-- 125. Two drink limit does not mean two kinds of drinks.   -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army   http​://skippyslist.com/?page_id=3

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Wed\, 16 Jan 2008 17​:01​:42 -0800 "Eric Wilhelm via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

?? ?? That "passthrough" is itself not right. ??No user-preferred Module​::Build arguments\, either mbuild_arg or buildflags\, will get passed to Makefile.PL under either CPAN or CPANPLUS shell. If the user defined these arguments\, why are they running Makefile.PL?

  In the case where both Makefile.PL and Build.PL exists\, the CPAN (or CPANPLUS) shell runs the one specified in another user preference prefer_installer (or prefer_makefile). It then apply the makepl_arg (or makemakerflags) or mbuild_arg (or buildflags) accordingly\, empty or not.

  Also\, mbuild_arg (or buildflags) and makepl_arg (or makemakerflags) are always defined. Their initial values are empty strings "".

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Thu\, 17 Jan 2008 10​:51​:43 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​: But I stand by my statement​: Emulation sucks. Don't use it if you don't have to. It causes all sorts of fascinating and expensive problems.

  I cannot agree no more. Please leave Makefile.PL to ExtUtils​::MakeMaker. It is simply not working. If you do not know what's going on\, it is better to remove that emulated "passthrough" Makefile.PL than shipping one. Removing it will make your module work again under CPAN or CPANPLUS or any future shells.

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Thu\, 17 Jan 2008 08​:54​:49 -0800 Michael G Schwern \schwern@&#8203;pobox\.com wrote​:

imacat wrote​:

Dear Michael G Schwern\, In that case\, could you please apply this patch to the Test-Harness-Straps? It's only one line\, and you don't have to maintain the compatibility at all and will drain no time and energy. As for the issue of being able to install it from a stock 5.8.8\, this is not a critical distribution at all. It's only there in case someone upgrades to Test​::Harness 3 and still needs Straps. 5.8.8 already has Straps\, so it's not likely to be an issue until 5.10.1 which will handle Build.PL out of the box just fine.

  You are right. Test​::Harness​::Straps is an abandoned module that should not be used anymore. And I said\, a Module​::Build module whose author without the knowledge of ExtUtils​::MakeMaker works better without a Makefile.PL than with one. I would not even bother to make this request *IF* it is not *in the core modules list*.

  The original problem is\, for a new Perl installation\, 5.6 or 5.8\, after issuing the "upgrade" command in the CPAN shell\, Test​::Harness​::Straps is the only one that fails after tens of upgrades. I can have an up-to-date Perl installation without Module​::Build\, if not for Test​::Harness​::Straps.

  I manage several servers (I believe you manage more)\, and install new Perl from time to time. Sometimes several installations on a same host. Only my development installation has Module​::Build. Production installations can live for years without Module​::Build\, if I do not see Test​::Harness​::Straps.

  So\, as Test​::Harness​::Straps is the only exception that always fails and always requires users to take special care\, I think I should file this request\, supplying a "compatible" Makefile.PL that works transparently for all the Perl maintainers that wish to keep their system up-to-date without knowing the details.

  You are having at least my thanks.

-- imacat ^_*' imacat@​mail.imacat.idv.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

Tavern IMACAT's http​://www.imacat.idv.tw/ Woman's Voice http​://www.wov.idv.tw/ TLUG List Manager http​://www.linux.org.tw/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

I cannot agree no more\.  Please leave Makefile\.PL to

ExtUtils​::MakeMaker. It is simply not working. If you do not know what's going on\, it is better to remove that emulated "passthrough" Makefile.PL than shipping one. Removing it will make your module work again under CPAN or CPANPLUS or any future shells.

Because MakeMaker doesn't do a lot of the things that Module​::Build does\, or they do them differently\, this approach will only go so far. As long as you only want to do very basic things it will work\, but get into any sort of customization or XS code and it's not going to fly. It keeps Module​::Build (and any future installer) shackled to MakeMaker conventions.

It won't work as a long term solution and we are now in the long term.

You are right\.  Test&#8203;::Harness&#8203;::Straps is an abandoned module that

should not be used anymore. And I said\, a Module​::Build module whose author without the knowledge of ExtUtils​::MakeMaker works better without a Makefile.PL than with one. I would not even bother to make this request *IF* it is not *in the core modules list*.

The original problem is\, for a new Perl installation\, 5\.6 or 5\.8\,

after issuing the "upgrade" command in the CPAN shell\, Test​::Harness​::Straps is the only one that fails after tens of upgrades. I can have an up-to-date Perl installation without Module​::Build\, if not for Test​::Harness​::Straps.

I would recommend following the suggestion of the CPAN shell and upgrade the CPAN shell first thing. The CPAN shell would then be able to handle Build.PL smoothly and it would solve the problem. That our installers don't update themselves is problematic and something I would like to fix (which is of itself a tricky problem).

I manage several servers \(I believe you manage more\)\, and install

new Perl from time to time. Sometimes several installations on a same host. Only my development installation has Module​::Build. Production installations can live for years without Module​::Build\, if I do not see Test​::Harness​::Straps.

Is there a problem with installing Module​::Build? Does it fail? Is there a reason you're keeping MB off your production servers?

So\, as Test&#8203;::Harness&#8203;::Straps is the only exception that always fails

and always requires users to take special care\, I think I should file this request\, supplying a "compatible" Makefile.PL that works transparently for all the Perl maintainers that wish to keep their system up-to-date without knowing the details.

I do appreciate that you filed the bug\, thank you. And again\, I'm sorry my live debugging session is giving you such a hard time.

-- Being faith-based doesn't trump reality.   -- Bruce Sterling

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Thu\, 17 Jan 2008 06​:19​:03 -0800 "John Peacock via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

H.Merijn Brand wrote​:

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test' (it is really one of the key points of its design). There is no reason to blindly create a Makefile for the few hardcore people who can't be bothered to look at the README file\, which it least in my case always

  1. If the user read the README file\, she would not run the "passthrough" Makefile.PL\, but Build.PL.

  2. If the user does not read the README file\, she will fail running "make" and "make test" with the "passthrough" Makefile.PL.

  Either way\, the "passthrough" Makefile.PLs are useless. I would suggest Module​::Build make it (and also "small") an alias of "compatible"\, or remove it entirely.

-- Best regards\, imacat ^_*' \imacat@&#8203;mail\.imacat\.idv\.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

\<\<Woman's Voice>> News​: http​://www.wov.idv.tw/ Tavern IMACAT's​: http​://www.imacat.idv.tw/ TLUG List Manager​: http​://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

On Thu\, 17 Jan 2008 06​:19​:03 -0800 "John Peacock via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

H.Merijn Brand wrote​:

If you don't/won't support EU​::MM\, why not include at least a Makefile.PL that barfs with a polite message that this porter has chosen to use the Module​::Build approach with a short message of how to use it and a Makefile that allows 'make test' to call 'Build test' (it is really one of the key points of its design). There is no reason to blindly create a Makefile for the few hardcore people who can't be bothered to look at the README file\, which it least in my case always 

 1\. If the user read the README file\, she would not run the

"passthrough" Makefile.PL\, but Build.PL.

 2\. If the user does not read the README file\, she will fail running

"make" and "make test" with the "passthrough" Makefile.PL.

Either way\, the "passthrough" Makefile\.PLs are useless\.  I would

suggest Module​::Build make it (and also "small") an alias of "compatible"\, or remove it entirely.

I believe you have misinterpreted John's use of "Makefile". I do not think he means to have a Makefile.PL which does not generate a Makefile but to not have a Makefile.PL at all\, just a Build.PL.

I'm not certain where this idea of Makefile.PLs which don't write a Makefile comes from. Module​::Build​::Compat generated passthrough Makefile.PLs *DO* generate a Makefile. "make" and "make test" will work. Individual distribution authors might write their own Makefile.PLs by hand\, but if you let Module​::Build do it for you it will all work.

Do you have specific examples of modules on CPAN which have Makefile.PLs which do not generate a Makefile? If so\, the author should be contacted and they should be asked to regenerate their Makefile.PL using Module​::Build​::Compat.

-- 101. I am not allowed to mount a bayonet on a crew-served weapon.   -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army   http​://skippyslist.com/?page_id=3

p5pRT commented 16 years ago

From imacat@mail.imacat.idv.tw

On Wed\, 23 Jan 2008 00​:35​:14 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​:

On Thu\, 17 Jan 2008 06​:19​:03 -0800 "John Peacock via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

H.Merijn Brand wrote​: Do you have specific examples of modules on CPAN which have Makefile.PLs which do not generate a Makefile? If so\, the author should be contacted and they should be asked to regenerate their Makefile.PL using Module​::Build​::Compat.

  I made a simple test. This is obviously not what I said. I was having a old and wrong impression on something. Sorry for this bothering.

-- imacat ^_*' imacat@​mail.imacat.idv.tw PGP Key​: http​://www.imacat.idv.tw/me/pgpkey.asc

Tavern IMACAT's http​://www.imacat.idv.tw/ Woman's Voice http​://www.wov.idv.tw/ TLUG List Manager http​://www.linux.org.tw/mailman/listinfo/tlug

p5pRT commented 16 years ago

From @schwern

imacat wrote​:

On Wed\, 23 Jan 2008 00​:35​:14 -0800 "Michael G Schwern via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

imacat wrote​:

On Thu\, 17 Jan 2008 06​:19​:03 -0800 "John Peacock via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

H.Merijn Brand wrote​: Do you have specific examples of modules on CPAN which have Makefile.PLs which do not generate a Makefile? If so\, the author should be contacted and they should be asked to regenerate their Makefile.PL using Module​::Build​::Compat.

I made a simple test\.  This is obviously not what I said\.  I was

having a old and wrong impression on something. Sorry for this bothering.

Jos dug through the Module​::Build bug tracker and found this rejected ticket​: http​://rt.cpan.org/Ticket/Display.html?id=19741

Which turned out to be a mistake on Eric Wilhelm's part with his modules. He made a mistake and messed up the generated Makefile.PLs. You can see it here in an old version of Math​::Geometry​::Planar​::Offset. http​://search.cpan.org/src/EWILHELM/Math-Geometry-Planar-Offset-1.04/Makefile.PL

Note the missing Module​::Build​::Compat->write_makefile() line.

So maybe that's where this idea came from.

-- 124. Two drink limit does not mean first and last.   -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army   http​://skippyslist.com/?page_id=3

p5pRT commented 16 years ago

From scratchcomputing@gmail.com

# from Michael G Schwern # on Wednesday 23 January 2008 14​:37​:

Which turned out to be a mistake on Eric Wilhelm's part with his modules.  He made a mistake and messed up the generated Makefile.PLs.

Yep. I had a subclass of Module​::Build which was supposed to enable optional features -- unfortunately because that was installed on my machine during './Build dist'\, it ended up in the the Makefile.PL. I suppose I noticed that somehow and deleted the line\, but didn't try 'perl Makefile.PL && make test' after (or maybe I copied it from elsewhere instead of setting create_makefile_pl.)

It was a M​::G​::P​::O distro issue and my fault. Not anything wrong with Module​::Build per-se\, though the 'optional subclass' thing doesn't DWIM in that regard and ./Build disttest doesn't check the Makefile.PL path.

In short\, don't do this and expect create_makefile_pl => passthru to work correctly​:

  my $build_class = 'Module​::Build';   my $custom_build = 'My​::Module​::Build​::Thing';   eval("require $custom_build;");   $build_class = $custom_build unless($@​);

  my $builder = $build_class->new(   ...

I suppose the subclass needs to jiggle the Compat bits for that to come out right...

And of course\, I had it in my Module​::Starter this way\, so there might be others\, but I've been catching them on the way out the door lately.

--Eric -- Chicken farmer's observation​: Clunk is the past tense of cluck.

  http​://scratchcomputing.com

p5pRT commented 14 years ago

From @obra

Test​::Harness​::Straps is no longer part of the perl core. Resolving.

p5pRT commented 14 years ago

@obra - Status changed from 'open' to 'resolved'