"PBP Module Recommendation Commentary" and recent CPAN ratings spammings

Hi,

First the related URLs:

 
http://www.perlfoundation.org/perl5/index.cgi?pbp_module_recommendation_comm
entary

and

http://cpanratings.perl.org/user/dandv

I wonder who created that page on perlfoundation.org? While it claims to be
the "community best practices" it even lists Module::Build as "maybe" I
think this page is mostly ridiculous.

What do you think?


0
burakgursoy
4/8/2009 4:11:12 PM
perl.module-authors 1604 articles. 0 followers. Follow

69 Replies
708 Views

Similar Articles

[PageSpeed] 45
Get it on Google Play
Get it on Apple App Store

> I wonder who created that page on perlfoundation.org?

It's a wiki.  You don't have to wonder:

http://www.perlfoundation.org/perl5/index.cgi?action=revision_list;page_name=pbp_module_recommendation_commentary

> While it claims to be
> the "community best practices" it even lists Module::Build as  
> "maybe" I
> think this page is mostly ridiculous.
>
> What do you think?

I think you should update it.

xoxo,
Andy


--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance



0
andy
4/8/2009 4:16:32 PM
On Wed, Apr 08, 2009 at 07:11:12PM +0300, Burak G�rsoy wrote:
> http://cpanratings.perl.org/user/dandv
> 
> I wonder who created that page on perlfoundation.org? While it claims to be
> the "community best practices" it even lists Module::Build as "maybe" I
> think this page is mostly ridiculous.
> 
> What do you think?

Dan can be overzealous, but I agree with almost everything that wiki page says.

In particular, saying "maybe" for Module::Build seems pretty reasonable to me,
since M::B vs. M::I is the emacs vs. vi of distribution installers, and the
summary "there is controversy, but it's definitely better than EUMM" is
certainly true.

hdp.
0
hdp
4/8/2009 4:20:20 PM
# from Hans Dieter Pearcey
# on Wednesday 08 April 2009 09:20:

>In particular, saying "maybe" for Module::Build seems pretty
> reasonable to me, since M::B vs. M::I is the emacs vs. vi of
> distribution installers, and the summary "there is controversy, but
> it's definitely better than EUMM" is certainly true.

As I've said before, this is silly.  It's a tool, so either it works or 
it doesn't.  We can't really have "controversy" about whether it works 
or how it works.

I can understand if one prefers the syntax of Module::Install and has no 
qualms about the questionable workarounds on top of EU::MM or has 
chosen the predictability of bundling in light of the risks of 
staleness.  But at this point, it is very possible to build all of that 
on top of Module::Build without all of the subtle and lingering 
gotchas.

It's a long, long ways from "emacs vs vi".  Feel free to make "rpm vs 
deb" analogies (with actual pros/cons.)  But, when sending someone a 
file, "edited in emacs or vi" doesn't matter.

If there has been any controversy, it's been about the fact that M::B 
was the first tool to break from "how we used to do it".  This exposed 
some flawed assumptions in the rest of the ecosystem which were not of 
M::B's making.  I hope we're past that (and I'm looking forward to the 
seamless addition of multiple alternative builders - perhaps even a 
less eye-bleedy way to do Inline:: modules.)

Analysis of real problems with M::B are welcomed in the bug tracker (or 
as code.)  This will help much more than snide "if only it worked" 
comments scattered around the interwebs and avoid making new users 
thing there's something wrong with M::B on account of it "not working 
in 1999".

Thanks,
Eric
-- 
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/8/2009 6:34:26 PM
On Wed, Apr 08, 2009 at 12:20:20PM -0400, Hans Dieter Pearcey wrote:

> and the summary "there is controversy, but it's definitely better
> than EUMM" is certainly true.

Only for certain values of "true".  Whether it's actually better for
*users* is a rather controversial subject.

-- 
David Cantrell | top google result for "topless karaoke murders"

   When a man is tired of London, he is tired of life
      -- Samuel Johnson
0
david
4/8/2009 6:52:41 PM
On Wed, Apr 08, 2009 at 11:34:26AM -0700, Eric Wilhelm wrote:
> # from Hans Dieter Pearcey
> # on Wednesday 08 April 2009 09:20:
> >In particular, saying "maybe" for Module::Build seems pretty
> > reasonable to me, since M::B vs. M::I is the emacs vs. vi of
> > distribution installers, and the summary "there is controversy, but
> > it's definitely better than EUMM" is certainly true.
> As I've said before, this is silly.  It's a tool, so either it works or 
> it doesn't.  We can't really have "controversy" about whether it works 
> or how it works.

Despite your saying that we can't, we do.  There is disagreement about
whether it's a good idea to use Module::Build, and merely denying that
the disagreement exists is ... well, it's silly.

-- 
David Cantrell | Hero of the Information Age

  The test of the goodness of a thing is its fitness for use.  If it
  fails on this first test, no amount of ornamentation or finish will
  make it any better, it will only make it more expensive and foolish.
     -- Frank Pick, lecture to the Design and Industries Assoc, 1916
0
david
4/8/2009 7:06:28 PM
On Wed, Apr 8, 2009 at 2:34 PM, Eric Wilhelm <enobacon@gmail.com> wrote:
> If there has been any controversy, it's been about the fact that M::B
> was the first tool to break from "how we used to do it". =C2=A0This expos=
ed

I'll add just my 2 cents to say that a good deal of the controversy
was hung up on getting good support for Module::Build into CPAN.pm and
CPANPLUS.  Between the recent work on CPANPLUS::Dist::Build and the
support for configure_requires in both CPAN.pm and CPANPLUS targeted
for 5.10.1, I think the controversy will be largely resolved.

After 5.10.1, the "official latest Perl" will have full Module::Build
support and the only lingering issue is what do to about those who
refuse to upgrade their toolchain.  That's not a controversy anymore,
that's a support issue.

-- David
0
david
4/8/2009 7:21:34 PM
# from David Cantrell
# on Wednesday 08 April 2009 12:06:

> As I've said before, this is silly. =A0It's a tool, so either it works
> or
>
>> it doesn't. =A0We can't really have "controversy" about whether it
>> works or how it works.
>
>Despite your saying that we can't, we do. =A0There is disagreement about
>whether it's a good idea to use Module::Build, and merely denying that
>the disagreement exists is ... well, it's silly.

You're saying there is a debate about whether stagnation is a good idea?

Dissenters are certainly free to hold their opinions without reason, but=20
I would rather they not inflict those irrationalities on others as=20
advice.

Please elaborate on why one should *not* use Module::Build.

Thanks,
Eric
=2D-=20
Peer's Law: The solution to the problem changes the problem.
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/8/2009 7:26:17 PM
On Apr 8, 2009, at 2:26 PM, Eric Wilhelm wrote:

> Please elaborate on why one should *not* use Module::Build.


Because the cost of learning it is non-zero.

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance




0
andy
4/8/2009 7:27:33 PM
On Wed, Apr 8, 2009 at 12:26 PM, Eric Wilhelm <enobacon@gmail.com> wrote:
> # from David Cantrell
> # on Wednesday 08 April 2009 12:06:
>
>> As I've said before, this is silly. =A0It's a tool, so either it works
>> or
>>
>>> it doesn't. =A0We can't really have "controversy" about whether it
>>> works or how it works.
>>
>>Despite your saying that we can't, we do. =A0There is disagreement about
>>whether it's a good idea to use Module::Build, and merely denying that
>>the disagreement exists is ... well, it's silly.
>
> You're saying there is a debate about whether stagnation is a good idea?
>
> Dissenters are certainly free to hold their opinions without reason, but
> I would rather they not inflict those irrationalities on others as
> advice.
>
> Please elaborate on why one should *not* use Module::Build.

One reason - because it's nonstandard.  It doesn't ship with Perl, and
all the classic Perl books say to use "perl Makefile.PL" and "make"
commands.
0
bill
4/8/2009 7:32:52 PM
# from Andy Lester
# on Wednesday 08 April 2009 12:27:

>> Please elaborate on why one should *not* use Module::Build.
>
>Because the cost of learning it is non-zero.

Fine.  But for *new* users?  Would you say EU::MM is easier to learn?

--Eric
-- 
"Everything goes wrong all at once."
--Quantized Revision of Murphy's Law
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/8/2009 7:33:35 PM
# from David Golden
# on Wednesday 08 April 2009 12:21:

>On Wed, Apr 8, 2009 at 2:34 PM, Eric Wilhelm <enobacon@gmail.com>=20
wrote:
>> If there has been any controversy, it's been about the fact that
>> M::B was the first tool to break from "how we used to do it". =C2=A0This
>> exposed
>
>I'll add just my 2 cents to say that a good deal of the controversy
>was hung up on getting good support for Module::Build into CPAN.pm and
>CPANPLUS. =C2=A0Between the recent work on CPANPLUS::Dist::Build and the
>support for configure_requires in both CPAN.pm and CPANPLUS targeted
>for 5.10.1, I think the controversy will be largely resolved.

I would call that "a good deal of pain", rather than controversy.  And=20
yes, thanks to your efforts (and to everyone else involved), that pain=20
is finally getting out of the way of progress.

Thanks,
Eric
=2D-=20
Chicken farmer's observation:  Clunk is the past tense of cluck.
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/8/2009 7:34:36 PM
On Apr 8, 2009, at 2:33 PM, Eric Wilhelm wrote:

>>> Please elaborate on why one should *not* use Module::Build.
>>
>> Because the cost of learning it is non-zero.
>
> Fine.  But for *new* users?  Would you say EU::MM is easier to learn?


Don't know.  Just saying why I have never switched: Because I've never  
heard a compelling enough reason to make the time investment.

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance




0
andy
4/8/2009 7:34:40 PM
On Wed, Apr 08, 2009 at 12:26:17PM -0700, Eric Wilhelm wrote:
> You're saying there is a debate about whether stagnation is a good idea?

I'm missing the connection between "stagnation" and "Module::Install", here.
Or were you talking only about EUMM?

In any case, the mere vitality of this thread indicates that saying "maybe" on
Module::Build is reasonable -- there are clearly strong differences of opinion
within the community, and it doesn't matter (to that subject) that you say very
forcefully that there is no reason not to use Module::Build, and call people
who do not want to use it "irrational", because that all is *part* of the
"controversy", not its conclusion.

hdp.
0
hdp
4/8/2009 7:35:35 PM
> -----Original Message-----
> From: Hans Dieter Pearcey [mailto:hdp.perl.module-authors@weftsoar.net]
> Sent: Wednesday, April 08, 2009 10:36 PM
> To: module-authors@perl.org
> Subject: Re: "a lot of controversy" about Module::Build

> In any case, the mere vitality of this thread indicates that saying
> "maybe" on
> Module::Build is reasonable -- there are clearly strong differences of
> opinion
> within the community, and it doesn't matter (to that subject) that you
> say very
> forcefully that there is no reason not to use Module::Build, and call
> people
> who do not want to use it "irrational", because that all is *part* of
> the
> "controversy", not its conclusion.

Well well... It looks like I've opened a can of worms :p 

I think M::B has a clean and understandable interface while EU::MM is
archaic (yes I know I didn't say something new). But to make a point: at my
previous $job, the back-end was converted from lots of  procedural cgi' s
into OOP and the the new system was built with M::B (around '06). Each
section was built as a CPAN distro (but they were lacking some parts). And
every code was somoke-tested each night. So, I think M::B is the way to go
for any new code. It has a solid interface and it is *in core*. 

And for the "Classic Perl Books" not mentioning M::B thing, they need an
update obviously. Most of them are several years (or even a decade) old.

0
burakgursoy
4/8/2009 7:55:44 PM
--1732368668-1356597425-1239220788=:9147
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.0.9999.0904081500011.9147@urth.org>

On Wed, 8 Apr 2009, Burak G=C3=BCrsoy wrote:

> http://www.perlfoundation.org/perl5/index.cgi?pbp_module_recommendation_c=
ommentary

I started that page, and various other folks have added to it. I think the=
=20
convention has been that if there's a strong yes or no and you disagree,=20
you change it to a maybe and present counter-arguments.

My main reason for starting it was to steer people away from completely=20
broken Damian-ware like Class::Std and such.


-dave

/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
--1732368668-1356597425-1239220788=:9147--
0
autarch
4/8/2009 8:01:27 PM
# from Hans Dieter Pearcey
# on Wednesday 08 April 2009 12:35:

>On Wed, Apr 08, 2009 at 12:26:17PM -0700, Eric Wilhelm wrote:
>> You're saying there is a debate about whether stagnation is a good
>> idea?
>
>I'm missing the connection between "stagnation" and "Module::Install",
> here. Or were you talking only about EUMM?

The PBP review says "maybe" on M::B, but nothing about M::I.  If you're 
going to recommend that new users use M::I instead of EU::MM or M::B, 
you really need to hang an even bigger maybe on that one.

EU::MM will "just work" because it never (except re INSTALLDIRS) changes 
and predates all of the client tools.  The drawback for authors is that 
it never changes and that functionality is limited.  The drawbacks for 
users are some subtle interface nits related to the fact that it uses 
make (and shells out to perl for every file manipulation.)   There's a 
less visible "lack of new features" - because it never changes.

M::B will "just work" as soon as all of the client tools are updated.  
The drawback for authors is getting bug reports from users who don't 
have updated client tools.  The drawback for users is also in the 
client tools.

M::I will "just work" until something goes wrong with the bundled 
version, at which point the author using it *must* release a new 
version to fix it.  It is also susceptible to EU::MM *ever* changing.  
Now that we have configure_requires, EU::MM might start changing, which 
would completely break M::I.

> and it doesn't matter
> (to that subject) that you say very forcefully that there is no
> reason not to use Module::Build, and call people who do not want to
> use it "irrational", because that all is *part* of the "controversy",

The pain of making it possible to have more than one build tool, or to 
have our build tools ever change (without bundling the world into each 
dist) has a long history.  I can understand that from the standpoint of 
people not having time to mess with it, but how much of the pain is 
just a result of the momentum of the pain?

--Eric
-- 
Speak softly and carry a big carrot.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/8/2009 8:05:13 PM
On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak G�rsoy wrote:
> I think M::B has a clean and understandable interface while EU::MM is
> archaic (yes I know I didn't say something new).

Any current argument about Perl installation tools is, as far as I can tell,
primarily a battle between Module::Build and Module::Install, with EUMM on a
stretcher by the sidelines.  Pitting M::B against EUMM makes your argument
neither fair nor compelling.

hdp.
0
hdp
4/8/2009 8:05:17 PM
> -----Original Message-----
> From: Dave Rolsky [mailto:autarch@urth.org]
> Sent: Wednesday, April 08, 2009 11:01 PM
> To: Burak G=C3=BCrsoy
> Cc: module-authors@perl.org
> Subject: Re: "PBP Module Recommendation Commentary" and recent CPAN
> ratings spammings

> I started that page, and various other folks have added to it. I think
> the
> convention has been that if there's a strong yes or no and you
> disagree,
> you change it to a maybe and present counter-arguments.
>=20
> My main reason for starting it was to steer people away from =
completely
> broken Damian-ware like Class::Std and such.

OK, the intention is good but the location (perlfoundation.org) of that =
page is not that good maybe, since someone flooded CPAN Ratings with a =
reference to that page.

0
burakgursoy
4/8/2009 8:33:45 PM
--000e0cd17cc0bfab000467112387
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 8, 2009 at 1:05 PM, Hans Dieter Pearcey <
hdp.perl.module-authors@weftsoar.net> wrote:

> On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak G=FCrsoy wrote:
> > I think M::B has a clean and understandable interface while EU::MM is
> > archaic (yes I know I didn't say something new).
>
> Any current argument about Perl installation tools is, as far as I can
> tell,
> primarily a battle between Module::Build and Module::Install, with EUMM o=
n
> a
> stretcher by the sidelines.  Pitting M::B against EUMM makes your argumen=
t
> neither fair nor compelling.
>

For the average simple module that's just a pm file or two, EUMM is the
least painful solution.  It comes with every version of Perl that a user
might possibly have, and it works the same in each of those Perl versions.
It may be clunky and lack many desirable fetures, but it works just fine in
most cases.

--000e0cd17cc0bfab000467112387
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Apr 8, 2009 at 1:05 PM, Hans Dieter Pear=
cey <span dir=3D"ltr">&lt;<a href=3D"mailto:hdp.perl.module-authors@weftsoa=
r.net">hdp.perl.module-authors@weftsoar.net</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 2=
04); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class=3D"im">On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak G=FCrsoy =
wrote:<br>
&gt; I think M::B has a clean and understandable interface while EU::MM is<=
br>
&gt; archaic (yes I know I didn&#39;t say something new).<br>
<br>
</div>Any current argument about Perl installation tools is, as far as I ca=
n tell,<br>
primarily a battle between Module::Build and Module::Install, with EUMM on =
a<br>
stretcher by the sidelines. =A0Pitting M::B against EUMM makes your argumen=
t<br>
neither fair nor compelling.<br>
<font color=3D"#888888"></font></blockquote><div><br>For the average simple=
 module that&#39;s just a pm file or two, EUMM is the least painful solutio=
n.=A0 It comes with every version of Perl that a user might possibly have, =
and it works the same in each of those Perl versions.=A0 It may be clunky a=
nd lack many desirable fetures, but it works just fine in most cases. <br>
</div></div>

--000e0cd17cc0bfab000467112387--
0
bill
4/8/2009 8:40:18 PM
Bill Ward wrote:
> On Wed, Apr 8, 2009 at 1:05 PM, Hans Dieter Pearcey 
> <hdp.perl.module-authors@weftsoar.net 
> <mailto:hdp.perl.module-authors@weftsoar.net>> wrote:
>
>     On Wed, Apr 08, 2009 at 10:55:44PM +0300, Burak G�rsoy wrote:
>     > I think M::B has a clean and understandable interface while
>     EU::MM is
>     > archaic (yes I know I didn't say something new).
>
>     Any current argument about Perl installation tools is, as far as I
>     can tell,
>     primarily a battle between Module::Build and Module::Install, with
>     EUMM on a
>     stretcher by the sidelines.  Pitting M::B against EUMM makes your
>     argument
>     neither fair nor compelling.
>
>
> For the average simple module that's just a pm file or two, EUMM is 
> the least painful solution.  It comes with every version of Perl that 
> a user might possibly have, and it works the same in each of those 
> Perl versions.  It may be clunky and lack many desirable fetures, but 
> it works just fine in most cases.
Erm... not in my experience.  For a simple pure-perl package, M::B 
turned out to be simpler to use when setting up a new package.  Since I 
don't use either CPAN or CPANPLUS, those details were a non-issue, and I 
let M::B create the Makefile.PL also.  Much less hassle.  It's why my 
new package was made with M::B, and why I transfered my other packages 
to M::B.

Note that I am at the lowest level of perl programmer here: pure perl, 
minimal use of dependencies, straightforward documentation.

    -john
0
jgamble
4/8/2009 9:01:40 PM
--1732368668-975081029-1239228439=:9147
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 8 Apr 2009, Burak G=C3=BCrsoy wrote:

>> -----Original Message-----
>> From: Dave Rolsky [mailto:autarch@urth.org]
>> Sent: Wednesday, April 08, 2009 11:01 PM
>> To: Burak G=C3=BCrsoy
>> Cc: module-authors@perl.org
>> Subject: Re: "PBP Module Recommendation Commentary" and recent CPAN
>> ratings spammings
>
>> I started that page, and various other folks have added to it. I think
>> the
>> convention has been that if there's a strong yes or no and you
>> disagree,
>> you change it to a maybe and present counter-arguments.
>>
>> My main reason for starting it was to steer people away from completely
>> broken Damian-ware like Class::Std and such.
>
> OK, the intention is good but the location (perlfoundation.org) of that=
=20
> page is not that good maybe, since someone flooded CPAN Ratings with a=20
> reference to that page.

So because someone assumes that a _wiki_ hosted at perlfoundation.org is=20
an official TPF thing, we should move the page?

Hey, everyone, it's a wiki. That means any dumbass like me can make or=20
edit pages.


-dave

/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
--1732368668-975081029-1239228439=:9147--
0
autarch
4/8/2009 10:07:19 PM
* On Wed, Apr 08 2009, Burak G=C3=BCrsoy wrote:
> OK, the intention is good but the location (perlfoundation.org) of
> that page is not that good maybe, since someone flooded CPAN Ratings
> with a reference to that page.

So?  If you haven't learned to take things you read on the Internet with
a grain of salt, then you deserve what you get.

All the code implementing the "recommended modules" is freely available
to read.  If you really want to know whether the code is good or not,
download the code, get a cup of coffee, open your favorite editor, and
play with it.  That will buy you a lot more than reading cpan-hatings or
some wiki will.

Regards,
Jonathan Rockway

--
use strict; print join ' ', Just::, another::, Perl::, hacker::
0
jon
4/8/2009 10:12:32 PM
> -----Original Message-----
> From: Jonathan Rockway [mailto:jon@jrock.us]
> Sent: Thursday, April 09, 2009 1:13 AM
> To: Burak G=C3=BCrsoy
> Cc: 'Dave Rolsky'; module-authors@perl.org
> Subject: Re: "PBP Module Recommendation Commentary" and recent CPAN
> ratings spammings

> So?  If you haven't learned to take things you read on the Internet
> with
> a grain of salt, then you deserve what you get.
>=20
> All the code implementing the "recommended modules" is freely =
available
> to read.  If you really want to know whether the code is good or not,
> download the code, get a cup of coffee, open your favorite editor, and
> play with it.  That will buy you a lot more than reading cpan-hatings
> or
> some wiki will.

Maybe you should learn to read first before replying anything.

0
burakgursoy
4/8/2009 10:23:43 PM
> -----Original Message-----
> From: Dave Rolsky [mailto:autarch@urth.org]
> Sent: Thursday, April 09, 2009 1:07 AM
> To: module-authors@perl.org
> Subject: RE: "PBP Module Recommendation Commentary" and recent CPAN
> ratings spammings

> So because someone assumes that a _wiki_ hosted at perlfoundation.org
> is
> an official TPF thing, we should move the page?

Well... it was just a thought :p
 
> Hey, everyone, it's a wiki. That means any dumbass like me can make or
> edit pages.


0
burakgursoy
4/8/2009 10:24:55 PM
* On Wed, Apr 08 2009, Burak G=C3=BCrsoy wrote:
> Maybe you should learn to read first before replying anything.

Maybe you should learn to write before "replying anything"?

:)

Seriously, though, do we really need to have a personal-attack-war?
Let's make fun of Python instead!

Regards,
Jonathan Rockway

--
print just =3D> another =3D> perl =3D> hacker =3D> if $,=3D$"
0
jon
4/8/2009 10:31:15 PM
IMHO, maybe a guidelines statement on the Ratings website would help. In
general, I think one should comment on "competing" modules within the
context of inline POD, and authors of such modules should avoid rating =
the
"competition" on this service.

One of my favorite examples of a well-written "See Also":
http://search.cpan.org/~odigity/Parallel-Simple-0.01/lib/Parallel/Simple.=
pm#
SEE_ALSO

I've got a CPAN module NCBIx::BigFetch that downloads sequences from =
NCBI,
so I will abstain from rating anything that does something similar (in =
say
BioPerl). If I need to comment on a module from that Bundle, I will do =
it my
"See Also". Of course I am free to rate YAML a 5 Star Module (which I =
just
did) because as a user of that module, I find it to be continuously =
useful
(and I will most likely never write a configuration module).=20

YMMV (which was already implied by "posting")

I think we would all like to be able to compare "competing" modules more
easily. There clearly is a marketplace of ideas, but our marketplace =
lacks
tools for shoppers. From a shopper's perspective - the ratings system =
itself
is not the tool; it's the data within the system. We need more (and more
thoughtful) data. Surely no one is complaining about the number of =
comments
that any given rater makes; more's the better.

I just signed up and added my first rating, and since I'm giving two
seminars this month on "useful CPAN modules", I will probably be adding =
more
very soon.

Incidentally - the commentary below was actually very timely for me. =
Please
feel free to send me your own suggestions (directly)! ;}

Thanks!

Roger Hall=20




-----Original Message-----
From: Burak G=FCrsoy [mailto:burakgursoy@gmx.net]=20
Sent: Wednesday, April 08, 2009 11:11 AM
To: module-authors@perl.org
Subject: "PBP Module Recommendation Commentary" and recent CPAN ratings
spammings

Hi,

First the related URLs:

=20
http://www.perlfoundation.org/perl5/index.cgi?pbp_module_recommendation_c=
omm
entary

and

http://cpanratings.perl.org/user/dandv

I wonder who created that page on perlfoundation.org? While it claims to =
be
the "community best practices" it even lists Module::Build as "maybe" I
think this page is mostly ridiculous.

What do you think?


0
rahall2
4/8/2009 11:09:57 PM
Eric Wilhelm wrote:
> # from David Cantrell
> # on Wednesday 08 April 2009 12:06:
> 
>>> As I've said before, this is silly.  It's a tool, so either it works
>>> or it doesn't.  We can't really have "controversy" about whether it
>>> works or how it works.
>> Despite your saying that we can't, we do.  There is disagreement about
>> whether it's a good idea to use Module::Build, and merely denying that
>> the disagreement exists is ... well, it's silly.
> You're saying there is a debate about whether stagnation is a good idea?

No.  Don't be silly.

> Dissenters are certainly free to hold their opinions without reason, but 
> I would rather they not inflict those irrationalities on others as 
> advice.

What you would rather has no bearing on what *is*.

And your belief that those who disagree with you are irrational is
both offensive and demonstrates that you've not actually bothered to
read those opinions.

> Please elaborate on why one should *not* use Module::Build.

That depends on who one is.  If you're writing specifically for people
who keep their toolchain and perl religiously up-to-date, then by all
means use Module::Build.  But if you're not, then using Module::Build is
silly because it hasn't been in core for very long.  I'm glad it is now
in core, because I think it superior to the alternatives in all ways
apart from *actually being installed*, and maybe in a coupla years I'll
consider using it.

-- 
David Cantrell | Official London Perl Mongers Bad Influence

What a lovely day!  Now watch me spoil it for you.
0
david
4/8/2009 11:17:57 PM
# from David Cantrell
# on Wednesday 08 April 2009 16:17:

>> Dissenters are certainly free to hold their opinions without reason,
>> but I would rather they not inflict those irrationalities on others
>> as advice.
>
>What you would rather has no bearing on what *is*.
>
>And your belief that those who disagree with you are irrational is
>both offensive and demonstrates that you've not actually bothered to
>read those opinions.

Please don't get offended or think that I've called you irrational.  I'm=20
simply pointing out that opinions stated without reasons are=20
unreasonable, not calling you unreasonable.

>> Please elaborate on why one should *not* use Module::Build.
>
>That depends on who one is. =A0If you're writing specifically for people
>who keep their toolchain and perl religiously up-to-date,

There's nothing religious about it.  You upgrade, it works better.

>then by all means use Module::Build. =A0But if you're not, then using
>Module::Build is silly because it hasn't been in core for very long.

That's not exactly a problem with Module::Build (not that I haven't put=20
energy into solving it.)

But, anyway, is it a problem we really need to be inflicting on new Perl=20
users?  Do they have to care if "somebody might be running 5.8.8=20
somewhere"?  With 5.10.0 out for well over a year now?

And anyway, if the trouble with using something is that it's "not core",=20
the fix is not to get it into the core.  Rather, we should try to=20
make "coreness" not matter.

Thanks,
Eric
=2D-=20
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
=2D-Donald Knuth
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/8/2009 11:49:56 PM
--286030772-586320180-1239235884=:12634
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

I hope you guys don't mind if I interject...

On Wed, 8 Apr 2009, Eric Wilhelm wrote:

>> That depends on who one is. =A0If you're writing specifically for people
>> who keep their toolchain and perl religiously up-to-date,
>
> There's nothing religious about it.  You upgrade, it works better.

That's a hugely optimistic and naive statement, even if it's true most of=
=20
the time in the Perl community.  Regressions happen.

> But, anyway, is it a problem we really need to be inflicting on new Perl
> users?  Do they have to care if "somebody might be running 5.8.8
> somewhere"?  With 5.10.0 out for well over a year now?

Hell, yes, *I* care.  Developers should be aware of portability if they
expect the code to run anywhere outside of the machines they control.  The
reality is that there are a lot of installations that lag current perl
releases by years, either because some OS versions are in maintenance-mode
only, or because many commercial Unices are always slow to upgrade.  As I
said before, regressions happen, and the "bleeding edge" is called
"bleeding" for a reason.  For those reason I still test my code back to=20
Perl 5.6.x.

> And anyway, if the trouble with using something is that it's "not core",
> the fix is not to get it into the core.  Rather, we should try to
> make "coreness" not matter.

You're right, but you're massively oversimplifying the problem.  Practical
reality has to have influence at some point.  I still use EU::MM myself
because I know that it will work pretty much everywhere.  Not everyone is
willing (and rightfully so) to install twenty other modules just to install
and use the functionality of one.

 =09--Arthur Corliss
 =09  Live Free or Die
--286030772-586320180-1239235884=:12634--
0
corliss
4/9/2009 12:11:24 AM
On Wed, 08 Apr 2009 16:11 -0800, "Arthur Corliss"
<corliss@digitalmages.com> wrote:
> I hope you guys don't mind if I interject...
>=20
> On Wed, 8 Apr 2009, Eric Wilhelm wrote:
>=20
> >> That depends on who one is. =C2=A0If you're writing specifically for p=
eople
> >> who keep their toolchain and perl religiously up-to-date,
> >
> > There's nothing religious about it.  You upgrade, it works better.
>=20
> That's a hugely optimistic and naive statement, even if it's true most of=
=20
> the time in the Perl community.  Regressions happen.

I'll speak to that. Module::Install 0.81 and 0.82 have bugs in the
DSL.pm "Domain Specific Language" addition to it.

I've passed information on them to Adam Kennedy (0.82 was a "first try"
fix that did not work completely) and I understand he'll be fixing them,
if he hasn't already.

--Curtis

--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and
pictures in HTML mail]

--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and pictures i=
n HTML mail]

0
lists
4/9/2009 12:31:14 AM
--As of April 8, 2009 4:49:56 PM -0700, Eric Wilhelm is alleged to have 
said:

> But, anyway, is it a problem we really need to be inflicting on new Perl
> users?  Do they have to care if "somebody might be running 5.8.8
> somewhere"?  With 5.10.0 out for well over a year now?

--As for the rest, it is mine.

Given that at work I have boxes running Perl 5.4.something that I'm not 
allowed to upgrade, Yes.  (And we just installed some brand-new boxes 
running the latest version of RedHat.  Comes with Perl 5.8.10.)

It takes _time_ for boxes to get upgraded.  Sometimes lots of time.

Daniel T. Staal  (I do actually use M::B, but I _hate_ the 'well it's been 
out for _X_ years now, so we shouldn't have to worry about it'.  If X is 
less than 10, you have to worry about it.  If it's more than 10, be 
prepared to worry about it if needed.)

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
0
DStaal
4/9/2009 12:49:59 AM
On Wed, 8 Apr 2009, Daniel Staal wrote:

> Daniel T. Staal  (I do actually use M::B, but I _hate_ the 'well it's been 
> out for _X_ years now, so we shouldn't have to worry about it'.  If X is less 
> than 10, you have to worry about it.  If it's more than 10, be prepared to 
> worry about it if needed.)

No, _you_ have to worry about it.

I, as a module author providing you a free product, don't have to give a 
damn. Realistically, authors give some amount of damn, but maybe not a 
full "I'll support Perl 5.004 for the poor slobs using ancient Red Hat 
boxes".

Personally, my target is generally the two most recent major releases. 
Once 5.10 had been out for a while, I stopped testing my modules against 
5.6. For new modules, I've been using 5.8-isms.


-dave

/*============================================================
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
============================================================*/
0
autarch
4/9/2009 12:58:33 AM
--As of April 8, 2009 7:58:33 PM -0500, Dave Rolsky is alleged to have said:

> I, as a module author providing you a free product, don't have to give a
> damn. Realistically, authors give some amount of damn, but maybe not a
> full "I'll support Perl 5.004 for the poor slobs using ancient Red Hat
> boxes".
>
> Personally, my target is generally the two most recent major releases.
> Once 5.10 had been out for a while, I stopped testing my modules against
> 5.6. For new modules, I've been using 5.8-isms.

--As for the rest, it is mine.

Point taken.  I just hate the attitude that it's too old to bother thinking 
about at all, especially if they are dismissing versions currently being 
distributed as 'current' by major vendors.  (Which was the case, when they 
were dismissing 5.8.8.)

(And the 5.4 is ancient _Sun_ boxen.  The ancient RedHat are running 5.8.0 
;) )

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
0
DStaal
4/9/2009 1:19:58 AM
# from Dave Rolsky
# on Wednesday 08 April 2009 17:58:

>I, as a module author providing you a free product, don't have to give
> a damn. Realistically, authors give some amount of damn, but maybe
> not a full "I'll support Perl 5.004 for the poor slobs using ancient
> Red Hat boxes".

Exactly.  If you treat Perl like a legacy language, there won't be any 
new users and you won't have any problems of some new code not being 
compatible with your old code because there won't be any new code.

--Eric
-- 
.... unsustainable.  And that word means something -- it doesn't just 
mean "we don't like it".
--Michael Pollan
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/9/2009 8:06:55 AM
----- Original Message ----=0A=0A> From: Andy Lester <andy@petdance.com>=0A=
>=0A> Don't know.  Just saying why I have never switched: Because I've neve=
r  =0A> heard a compelling enough reason to make the time investment.=0A=0A=
Exactly! Thank you, Andy++=0A=0AMe?  I use M::B for most of my modules.  Ge=
nerally don't need to, but I provide a Makefile.PL for those who don't like=
 MB.  However, if I have complicated build needs, EU::MM is very, very hard=
 to work with.=0A=0A =0AI have no idea why people debate this.  MB and MI a=
re clearly superior to EU::MM [1], but so what?  Don't need 'em?  Don't use=
 'em.=0A=0AI'm sorry.  What were people saying again?=0A=0ACheers,=0AOvid=
=0A=0A1.  This is according to the *maintainers* of EU::MM. Lots of people =
who've never written a Makefile which must run on an unknown operating syst=
em with an unknown version of "make" have different opinions, though.=0A--=
=0ABuy the book         - http://www.oreilly.com/catalog/perlhks/=0ATech bl=
og            - http://use.perl.org/~Ovid/journal/=0ATwitter              -=
 http://twitter.com/OvidPerl=0AOfficial Perl 6 Wiki - http://www.perlfounda=
tion.org/perl6=0A
0
publiustemp
4/9/2009 11:47:59 AM
On Wed, Apr 08, 2009 at 04:11:24PM -0800, Arthur Corliss wrote:
> On Wed, 8 Apr 2009, Eric Wilhelm wrote:
> >>That depends on who one is. �If you're writing specifically for people
> >>who keep their toolchain and perl religiously up-to-date,
> >There's nothing religious about it.  You upgrade, it works better.

Sure.  But if you don't keep your toolchain up-to-date (and I know I
never did until I actually needed to because CPAN::Reporter required it)
then most stuff Just Works anyway, and if it didn't I was inclined to
just assume that the module author couldn't be bothered to write a
decent install script, rather than wonder if the tools (like CPAN.pm)
that worked for nigh-on everything else were at fault.

> That's a hugely optimistic and naive statement, even if it's true most of 
> the time in the Perl community.

But lots of people who use modules from the CPAN aren't really in the
perl community, and that's important.  Actually, there are lots of
people *in* the community who don't keep their toolchain up to date and
have no idea why it might be a good idea to upgrade from the CPAN.pm
that they installed a few years ago.

> >But, anyway, is it a problem we really need to be inflicting on new Perl
> >users?  Do they have to care if "somebody might be running 5.8.8
> >somewhere"?  With 5.10.0 out for well over a year now?
> Hell, yes, *I* care.  Developers should be aware of portability if they
> expect the code to run anywhere outside of the machines they control.

Yes!

I care because not all my machines have been upgraded to 5.10.  I care
because not all the machines at work have been upgraded.  I care because
if I deliberately restrict my code to 5.10 only, then I restrict the
number of people who will be inclined to do my work for me and send
patches to fix my bugs.

A common plaint I hear about perl code *from people outside the
community* is that we have too many dependencies and our code is too
hard to install.  And I can sympathise.  If you don't know how to
configure CPAN.pm to automagically follow dependencies (incidentally,
why is the default prerequisites_policy still 'ask' and not 'follow'?)
then it's a gigantic pain in the arse.  If on top of that you want them
to *upgrade perl* they're going to think you're mad.

And we should care about people outside the community, because they
vastly outnumber those of us *in* the community.  They and their
opinions are important because they do things like influence which
technologies their employers use, and consequently how many jobs there
are for us.

-- 
David Cantrell | London Perl Mongers Deputy Chief Heretic

Stepped on something soft and wobbly.
Struck a match.
Found it was a dead Chinaman.

    -- Sir George Scott
0
david
4/9/2009 12:10:22 PM
# from David Cantrell
# on Thursday 09 April 2009 05:10:

>>>But, anyway, is it a problem we really need to be inflicting on new
>>> Perl users? =A0Do they have to care if "somebody might be running
>>> 5.8.8 somewhere"? =A0With 5.10.0 out for well over a year now?

>I care because ...

You don't exactly qualify as a "new user", though :-)

>A common plaint I hear about perl code *from people outside the
>community* is that we have too many dependencies and our code is too
>hard to install. =A0... =A0If on top of that you want
> them to *upgrade perl* they're going to think you're mad.

Ruby didn't seem to have a problem getting installed.

>And we should care about people outside the community, because they
>vastly outnumber those of us *in* the community. =A0They and their
>opinions are important because they do things like influence which
>technologies their employers use, and consequently how many jobs there
>are for us.

I've never heard "we don't use Perl because it's hard to install", I've=20
only heard "we can't find programmers".

The recommendations we make to new programmers are met with limited=20
patience.  Do you recommend that they use EU::MM on account of=20
M::B "not working" on a system which hasn't been upgraded in 10 years? =20
IMO, that's getting off on the wrong foot for reasons which aren't=20
worth it.  By the time you need to explain how to do something special=20
with EU::MM, you could easily explain the compatibility issues of M::B=20
and the boring history lesson (and if you've gotten that far, we've=20
passed "newbie".)

And for those who would recommend M::I, would you also explain the=20
pitfalls of that, or simply leave it as "what you don't know yet won't=20
hurt you yet"?

=2D-Eric
=2D-=20
perl -e 'srand; print join(" ",sort({rand() < 0.5}
  qw(sometimes it is important to be consistent)));'
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/9/2009 4:21:48 PM
On Thu, 9 Apr 2009, Eric Wilhelm wrote:

>> I, as a module author providing you a free product, don't have to give
>> a damn. Realistically, authors give some amount of damn, but maybe
>> not a full "I'll support Perl 5.004 for the poor slobs using ancient
>> Red Hat boxes".
>
> Exactly.  If you treat Perl like a legacy language, there won't be any
> new users and you won't have any problems of some new code not being
> compatible with your old code because there won't be any new code.

But if you treat Perl like there's only new installations out there you're
going to be ignoring a huge installed base of older machines, and your code
won't get used.

You guys have the right to do whatever you want with your code, and I'm not
advocating that everyone should support fifteen years of Perl revisions.  I
am, however, saying that if you really want the Perl community to largely
benefit from contributions you need to be conscious of what the installed
base out there is using.

I highly doubt the majority of Perl *users* (not developers) out there are
as bleeding edge as yourselves.

 	--Arthur Corliss
 	  Live Free or Die
0
corliss
4/9/2009 4:23:59 PM
On Thu, 9 Apr 2009, David Cantrell wrote:

>> That's a hugely optimistic and naive statement, even if it's true most of
>> the time in the Perl community.
>
> But lots of people who use modules from the CPAN aren't really in the
> perl community, and that's important.  Actually, there are lots of
> people *in* the community who don't keep their toolchain up to date and
> have no idea why it might be a good idea to upgrade from the CPAN.pm
> that they installed a few years ago.

I think you misread my statement.  I was saying that assuming everything
"just works better" because it's a newer rev is, again, optimistic and
naive.  For that reason many of us choose to lag simply to let you blokes
that like cutting yourselves on the bleeding edge sort out the conflicts
for us.  :-)  For that reason I won't adopt Eric's philosophy of wanton
upgrading.

>>> But, anyway, is it a problem we really need to be inflicting on new Perl
>>> users?  Do they have to care if "somebody might be running 5.8.8
>>> somewhere"?  With 5.10.0 out for well over a year now?
>> Hell, yes, *I* care.  Developers should be aware of portability if they
>> expect the code to run anywhere outside of the machines they control.
>
> Yes!
>
> I care because not all my machines have been upgraded to 5.10.  I care
> because not all the machines at work have been upgraded.  I care because
> if I deliberately restrict my code to 5.10 only, then I restrict the
> number of people who will be inclined to do my work for me and send
> patches to fix my bugs.
>
> A common plaint I hear about perl code *from people outside the
> community* is that we have too many dependencies and our code is too
> hard to install.  And I can sympathise.  If you don't know how to
> configure CPAN.pm to automagically follow dependencies (incidentally,
> why is the default prerequisites_policy still 'ask' and not 'follow'?)
> then it's a gigantic pain in the arse.  If on top of that you want them
> to *upgrade perl* they're going to think you're mad.
>
> And we should care about people outside the community, because they
> vastly outnumber those of us *in* the community.  They and their
> opinions are important because they do things like influence which
> technologies their employers use, and consequently how many jobs there
> are for us.

Amen.  I bow to your more eloquent explanation.

 	--Arthur Corliss
 	  Live Free or Die
0
corliss
4/9/2009 4:34:56 PM
On Thu, Apr 09, 2009 at 09:21:48AM -0700, Eric Wilhelm wrote:
> # from David Cantrell on Thursday 09 April 2009 05:10:
> >And we should care about people outside the community, because they
> >vastly outnumber those of us *in* the community. �They and their
> >opinions are important because they do things like influence which
> >technologies their employers use, and consequently how many jobs there
> >are for us.
> I've never heard "we don't use Perl because it's hard to install", I've 
> only heard "we can't find programmers".

Oh I've definitely heard "we don't use perl because the dependencies are
so fragile, you just look at them wrong and they don't want to play".
From people who are both experienced sysadmins and who also write code in
other languages.

> The recommendations we make to new programmers are met with limited 
> patience.  Do you recommend that they use EU::MM on account of 
> M::B "not working" on a system which hasn't been upgraded in 10 years?  

No.  But what about a system where the toolchain's not been touched for
three years?  Those are awfully common, and three years is a fairly
common upgrade cycle in business, as that's quite often how long it
takes to fully depreciate the hardware.  The other common cycle being
five years.  So every three years, they get new hardware, the sysadmins
take the opportunity to put a new release of $OS on it, which comes with
a newer perl, and the developers rejoice at having an opportunity to
actually deploy the shiny new version of perl that they've been playing
with in their sandboxes.

That's why maybe in a coupla years I'll consider using it.  That'll be
three (and a bit) years after 5.10 was released, and so when we can
expect a reasonable chunk of the deployed toolchain to be up to scratch.

-- 
David Cantrell | Minister for Arbitrary Justice

    fdisk format reinstall, doo-dah, doo-dah;
    fdisk format reinstall, it's the Windows way
0
david
4/9/2009 5:01:49 PM
--286030772-1635156680-1239297825=:7280
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 9 Apr 2009, Eric Wilhelm wrote:

>> A common plaint I hear about perl code *from people outside the
>> community* is that we have too many dependencies and our code is too
>> hard to install. =A0... =A0If on top of that you want
>> them to *upgrade perl* they're going to think you're mad.
>
> Ruby didn't seem to have a problem getting installed.

There's a huge difference in installing a new software stack altogether and
updating something that's there by default on just about every UNIX out
there.  Given how many OS's use Perl scripts for administrative tasks I
wouldn't necessarily be surprised to learn that some of them also bundle
some CPAN modules with their package just to keep that running.  So, if you=
r
vendor doesn't update the system perl, you shouldn't be overwriting it with
no regard to the consequences.

Even more so when you have people installing modules via CPAN and
outside of package management.  They always run the risk of updating perl
and forgetting a litany of other modules that were installed for various
scripts, etc., which use XS modules, etc.  The anticipation of that kind of
triage is more than enough reason for a lot of people to avoid updating
perl.  How many sys-admins and non-developers are aware of perlocal.pod?

> I've never heard "we don't use Perl because it's hard to install", I've
> only heard "we can't find programmers".

Perl isn't hard to install.  It is not, however, trivial to upgrade without
having a lot of unintended consequences for the reasons I detailed above.
If the recommendation is to install a new version of perl in /usr/local,
then this becomes much less of an issue.

> The recommendations we make to new programmers are met with limited
> patience.  Do you recommend that they use EU::MM on account of
> M::B "not working" on a system which hasn't been upgraded in 10 years?
> IMO, that's getting off on the wrong foot for reasons which aren't
> worth it.  By the time you need to explain how to do something special
> with EU::MM, you could easily explain the compatibility issues of M::B
> and the boring history lesson (and if you've gotten that far, we've
> passed "newbie".)

There are definitely cases where you would want to abandon EU::MM, but you
have to do so with the conscious realization that you're reducing the size
of the audience that could benefit from your code at that point.  If gettin=
g
a complex installer working under EU::MM is that painful I can certainly
understand you not wanting to make that sacrifice.  It's all good.  But as
long as there are more installations out there with EU::MM than there are
M::B it only makes sense that you accomodate them where you can, so the
largest segment of the community gets the benefit.

Ultimately, isn't that what matters?  If we didn't want to make a
contribution we wouldn't be releasing it on CPAN, right?  For that reason
I'm going to wait until M::B becomes predominantly available before
considering a switch.  Until then I use EU::MM and still test against Perl=
=20
5.6.

 =09--Arthur Corliss
 =09  Live Free or Die
--286030772-1635156680-1239297825=:7280--
0
corliss
4/9/2009 5:23:45 PM
# from David Cantrell
# on Thursday 09 April 2009 10:01:

>> The recommendations we make to new programmers are met with limited
>> patience. =A0Do you recommend that they use EU::MM on account of
>> M::B "not working" on a system which hasn't been upgraded in 10
>> years? =A0
>
>No. =A0But what about a system where the toolchain's not been touched
> for three years? ... fairly common upgrade cycle in business

I still would not recommend EU::MM to a new user on this account.

If you're installing today's code from the CPAN directly on outdated=20
production machines, you're doing it wrong.  That's not a problem with=20
M::B, and it is not a new user's immediate concern.

Sure, you'll need to brief a new hire on your deployment mechanism and=20
its caveats, but that's true at any business.

=2D-Eric
=2D-=20
Entia non sunt multiplicanda praeter necessitatem.
=2D-Occam's Razor
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/9/2009 5:29:42 PM
* On Thu, Apr 09 2009, Arthur Corliss wrote:
> On Thu, 9 Apr 2009, Eric Wilhelm wrote:
>
>>> A common plaint I hear about perl code *from people outside the
>>> community* is that we have too many dependencies and our code is too
>>> hard to install. =C2=A0... =C2=A0If on top of that you want
>>> them to *upgrade perl* they're going to think you're mad.
>>
>> Ruby didn't seem to have a problem getting installed.
>
> There's a huge difference in installing a new software stack altogether a=
nd
> updating something that's there by default on just about every UNIX out
> there.  Given how many OS's use Perl scripts for administrative tasks I
> wouldn't necessarily be surprised to learn that some of them also bundle
> some CPAN modules with their package just to keep that running.  So, if y=
our
> vendor doesn't update the system perl, you shouldn't be overwriting it wi=
th
> no regard to the consequences.
>
> Even more so when you have people installing modules via CPAN and
> outside of package management.  They always run the risk of updating perl
> and forgetting a litany of other modules that were installed for various
> scripts, etc., which use XS modules, etc.  The anticipation of that kind =
of
> triage is more than enough reason for a lot of people to avoid updating
> perl.  How many sys-admins and non-developers are aware of perlocal.pod?

Most people I know compile one perl for each of their applications.  The
OS perl is for the OS, not for you.  (OK, and packages the OS installs.
Basically, if you plan on modifying anything perl touches in any way,
you want your own perl install for that.  Otherwise, yeah, you will
break your OS.  Why would this surprise anyone?)

Admittedly, it would be nice if this process were easier, although I
think using local::lib for development and PAR for deployment is a
pretty good off-the-shelf solution.

Regards,
Jonathan Rockway

--
print just =3D> another =3D> perl =3D> hacker =3D> if $,=3D$"
0
jon
4/9/2009 6:26:50 PM
--000e0cd156241e84690467236a49
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway <jon@jrock.us> wrote:

>
> Most people I know compile one perl for each of their applications.  The
> OS perl is for the OS, not for you.  (OK, and packages the OS installs.
> Basically, if you plan on modifying anything perl touches in any way,
> you want your own perl install for that.  Otherwise, yeah, you will
> break your OS.  Why would this surprise anyone?)
>

You'd be surprised...

--000e0cd156241e84690467236a49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockwa=
y <span dir=3D"ltr">&lt;<a href=3D"mailto:jon@jrock.us">jon@jrock.us</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: =
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;=
">
<div class=3D"im"><br>
</div>Most people I know compile one perl for each of their applications. =
=A0The<br>
OS perl is for the OS, not for you. =A0(OK, and packages the OS installs.<b=
r>
Basically, if you plan on modifying anything perl touches in any way,<br>
you want your own perl install for that. =A0Otherwise, yeah, you will<br>
break your OS. =A0Why would this surprise anyone?)<br>
</blockquote><div><br>You&#39;d be surprised...<br></div></div>

--000e0cd156241e84690467236a49--
0
bill
4/9/2009 6:28:28 PM
* On Thu, Apr 09 2009, Bill Ward wrote:
> On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway <jon@jrock.us> wrote:
>
>     Most people I know compile one perl for each of their applications. =
=C2=A0The
>     OS perl is for the OS, not for you. =C2=A0(OK, and packages the OS in=
stalls.
>     Basically, if you plan on modifying anything perl touches in any way,
>     you want your own perl install for that. =C2=A0Otherwise, yeah, you w=
ill
>     break your OS. =C2=A0Why would this surprise anyone?)
>
> You'd be surprised...

So maybe we should try educating users, instead of holding back the
ENTIRE COMMUNITY for their sake.

--
print just =3D> another =3D> perl =3D> hacker =3D> if $,=3D$"
0
jon
4/9/2009 7:10:38 PM
--000e0cd21470988ab40467244500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Apr 9, 2009 at 12:10 PM, Jonathan Rockway <jon@jrock.us> wrote:

> * On Thu, Apr 09 2009, Bill Ward wrote:
> > On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway <jon@jrock.us> wrote:
> >
> >     Most people I know compile one perl for each of their applications.
>  The
> >     OS perl is for the OS, not for you.  (OK, and packages the OS
> installs.
> >     Basically, if you plan on modifying anything perl touches in any way,
> >     you want your own perl install for that.  Otherwise, yeah, you will
> >     break your OS.  Why would this surprise anyone?)
> >
> > You'd be surprised...
>
> So maybe we should try educating users, instead of holding back the
> ENTIRE COMMUNITY for their sake.
>

How about you write a "how to manage Perl on your system" doc and get it
into the core as a new perlxyz perldoc file then.

--000e0cd21470988ab40467244500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 9, 2009 at 12:10 PM, Jonatha=
n Rockway <span dir=3D"ltr">&lt;<a href=3D"mailto:jon@jrock.us">jon@jrock.u=
s</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;">
<div><div></div><div class=3D"h5">* On Thu, Apr 09 2009, Bill Ward wrote:<b=
r>
&gt; On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway &lt;<a href=3D"mailt=
o:jon@jrock.us">jon@jrock.us</a>&gt; wrote:<br>
&gt;<br>
&gt; =A0 =A0 Most people I know compile one perl for each of their applicat=
ions. =A0The<br>
&gt; =A0 =A0 OS perl is for the OS, not for you. =A0(OK, and packages the O=
S installs.<br>
&gt; =A0 =A0 Basically, if you plan on modifying anything perl touches in a=
ny way,<br>
&gt; =A0 =A0 you want your own perl install for that. =A0Otherwise, yeah, y=
ou will<br>
&gt; =A0 =A0 break your OS. =A0Why would this surprise anyone?)<br>
&gt;<br>
&gt; You&#39;d be surprised...<br>
<br>
</div></div>So maybe we should try educating users, instead of holding back=
 the<br>
ENTIRE COMMUNITY for their sake.<br>
<div><div></div><div class=3D"h5"></div></div></blockquote><div><br>How abo=
ut you write a &quot;how to manage Perl on your system&quot; doc and get it=
 into the core as a new perlxyz perldoc file then.<br></div></div>

--000e0cd21470988ab40467244500--
0
bill
4/9/2009 7:29:50 PM
* On Thu, Apr 09 2009, Bill Ward wrote:
> How about you write a "how to manage Perl on your system" doc and get it into the core
> as a new perlxyz perldoc file then.

That is a very good idea.

Of course, the people that will update to a version of perl that
includes this doc probably won't need it ;)

--
print just => another => perl => hacker => if $,=$"
0
jon
4/9/2009 8:30:58 PM
# from Jonathan Rockway
# on Thursday 09 April 2009 13:30:

>* On Thu, Apr 09 2009, Bill Ward wrote:
>> How about you write a "how to manage Perl on your system" doc and
>> get it into the core as a new perlxyz perldoc file then.
>
>That is a very good idea.
>
>Of course, the people that will update to a version of perl that
>includes this doc probably won't need it ;)

If everyone can get past the idea that something non-core is somehow 
unusable, a fine document already exists

 http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices

--Eric
-- 
[...proprietary software is better than gpl because...] "There is value
in having somebody you can write checks to, and they fix bugs."
--Mike McNamara (president of a commercial software company)
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/9/2009 9:20:31 PM
On Thu, 09 Apr 2009 14:20 -0700, "Eric Wilhelm" <enobacon@gmail.com>
wrote:
>  http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices
> 
> --Eric

Ok.  Now we need to find someplace appropriate that we can convince
something in core to link to it.

I do have to admit, I like it (and not just because I like the line that
says "Windows is the exception, Strawberry Perl does a much better job
packaging Perl and tweaking it for Windows than you can (and if you
think you can better, please contribute to Strawberry)."

--Curtis

--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and
pictures in HTML mail]
--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]

0
lists
4/9/2009 9:43:59 PM
Jonathan Rockway <jon@jrock.us> writes:

> * On Thu, Apr 09 2009, Arthur Corliss wrote:

[...]

>> Even more so when you have people installing modules via CPAN and
>> outside of package management.  They always run the risk of updating perl
>> and forgetting a litany of other modules that were installed for various
>> scripts, etc., which use XS modules, etc.  The anticipation of that kind of
>> triage is more than enough reason for a lot of people to avoid updating
>> perl.  How many sys-admins and non-developers are aware of perlocal.pod?
>
> Most people I know compile one perl for each of their applications.  The
> OS perl is for the OS, not for you.  (OK, and packages the OS installs.
> Basically, if you plan on modifying anything perl touches in any way,
> you want your own perl install for that.  Otherwise, yeah, you will
> break your OS.  Why would this surprise anyone?)

I have to say, I have used the OS-provided Perl for everything since
Perl 5 started coming with the OS.  Anything else would be a support
nightmare for small projects.  I would find it very hard to convince
consulting clients to take on the support costs of maintaining a
separate version of Perl, with a separate process for security
updates, etc.

I do install modules someplace like '/usr/local/perl' so the OS Perl
doesn't generally see them, and I don't go around making random
changes, but the OS Perl has always worked fine for me, even for
fairly complicated projects.

----Scott.
0
sgifford
4/9/2009 10:15:41 PM
# from Curtis Jewell
# on Thursday 09 April 2009 14:43:

>On Thu, 09 Apr 2009 14:20 -0700, Eric Wilhelm wrote:
>>If everyone can get past the idea that something non-core is somehow=20
>>unusable, a fine document already exists
>> =A0http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practic=
es
>
>Ok. =A0Now we need to find someplace appropriate that we can convince
>something in core to link to it.

Joking, right?  There's no need for "something in core" and it is=20
already "someplace appropriate".

The important attributes for this sort of information are that it is
current, correct, and findable.

  http://www.google.com/search?q=3Dperl+administration+best+practice

=2D-Eric
=2D-=20
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
=2D-E.B. White
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/9/2009 11:37:09 PM
Only halfway. It will not hurt, and will probably help, to be linked
from more places.

http://www.google.com/search?q=link%3Ahttp%3A%2F%2Fwww.perlfoundation.org%2Fperl5%2Findex.cgi%3Fperl_best_admin_practices

looks awfully empty. (I'll throw a link to it in my use.perl journal in
the next few days, to help the cause.)

On Thu, 09 Apr 2009 16:37 -0700, "Eric Wilhelm" <enobacon@gmail.com>
wrote:
> Joking, right?  There's no need for "something in core" and it is 
> already "someplace appropriate". 

--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and
pictures in HTML mail]
--
Curtis Jewell
swordsman@csjewell.fastmail.us

%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears

[I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]

0
lists
4/10/2009 12:04:44 AM
--Sig_/8T969tkL2J4cOwOrnaU9Nf9
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 9 Apr 2009 04:47:59 -0700 (PDT)
Ovid <publiustemp-moduleauthors2@yahoo.com> wrote:

> Me?  I use M::B for most of my modules.  Generally don't need to, but I p=
rovide a Makefile.PL for those who don't like MB.  However, if I have compl=
icated build needs, EU::MM is very, very hard to work with.

I find this too. Of all my modules, any of them that don't have XS code
in them simply provide a dual Build.PL / Makefile.PL as written by M::B's
create_makefile_pl =3D> 'traditional'  setting.

It only becomes even vaguely complicated on a few of my XS ones, where
M::B expects to find lib/Foo/Bar.xs whereas EU::MM wants only Bar.xs

This random inconsistency annoys me - IMHO M::B's behaviour here is much
more preferable, for reasons of being able to find the code, of making
the file unique in case I want more than one,...

Furthermore I just find M::B to be nicer from an ideological perspective.
EU::MM writes a Makefile, so we can use GNU make or BSD make or MSVC
make or... why, exactly? M::B is written in perl. It works in perl. I
-generally- dislike build tools to rely on other languages, but when it's
a build system _for perl_, I suspect one could make a reasonable case for
it :)

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

--Sig_/8T969tkL2J4cOwOrnaU9Nf9
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJ32MFvLS2TC8cBo0RAhLPAJ95m7eBgvIOWwgoLBpHNBc2c/leqQCeMs6l
ZMQs6yQPD5a1avuliyXBK7E=
=zRaa
-----END PGP SIGNATURE-----

--Sig_/8T969tkL2J4cOwOrnaU9Nf9--
0
leonerd
4/10/2009 3:17:25 PM
> -----Original Message-----
> From: Paul LeoNerd Evans [mailto:leonerd@leonerd.org.uk]
> Sent: Friday, April 10, 2009 6:17 PM
> To: Ovid
> Cc: module-authors@perl.org
> Subject: Re: "a lot of silliness" about Module::Build
> 
> I find this too. Of all my modules, any of them that don't have XS code
> in them simply provide a dual Build.PL / Makefile.PL as written by
> M::B's create_makefile_pl => 'traditional'  setting.

I'm bundling a normal Makefile.PL for now but I think that I'll eventually
use that option. But I always use M::B to build distributions and never
duplicate that part in Makefile.PL. It's only there for compatibility
nothing else.

> It only becomes even vaguely complicated on a few of my XS ones, where
> M::B expects to find lib/Foo/Bar.xs whereas EU::MM wants only Bar.xs
> 
> This random inconsistency annoys me - IMHO M::B's behaviour here is
> much more preferable, for reasons of being able to find the code, of
> making the file unique in case I want more than one,...

I've experienced the same issue in one of my modules, but that's easy to fix
by adding this:

    xs_files => { 'Bar.xs' => 'lib/Foo/Bar.xs' },

then you can use a regular Makefile.PL too.




0
burakgursoy
4/10/2009 4:02:00 PM
Hi Burak:

2009/4/10 Burak G=C3=BCrsoy <burakgursoy@gmx.net>:
>> -----Original Message-----
>> From: Paul LeoNerd Evans [mailto:leonerd@leonerd.org.uk]
>> Sent: Friday, April 10, 2009 6:17 PM
>> To: Ovid
>> Cc: module-authors@perl.org
>> Subject: Re: "a lot of silliness" about Module::Build
>>
>> I find this too. Of all my modules, any of them that don't have XS code
>> in them simply provide a dual Build.PL / Makefile.PL as written by
>> M::B's create_makefile_pl =3D> 'traditional' =C2=A0setting.
>
> I'm bundling a normal Makefile.PL for now but I think that I'll eventuall=
y
> use that option. But I always use M::B to build distributions and never
> duplicate that part in Makefile.PL. It's only there for compatibility
> nothing else.
>
>> It only becomes even vaguely complicated on a few of my XS ones, where
>> M::B expects to find lib/Foo/Bar.xs whereas EU::MM wants only Bar.xs
>>
>> This random inconsistency annoys me - IMHO M::B's behaviour here is
>> much more preferable, for reasons of being able to find the code, of
>> making the file unique in case I want more than one,...
>
> I've experienced the same issue in one of my modules, but that's easy to =
fix
> by adding this:
>
> =C2=A0 =C2=A0xs_files =3D> { 'Bar.xs' =3D> 'lib/Foo/Bar.xs' },
>
> then you can use a regular Makefile.PL too.
>
When developing an XS module, I came to the same problem. But then I
just gave up on MakeMaker, and instead made it a passthrough for M::B

I chose to do this so that I could put all my C code into its own src/
folder, and install from there.
>
>
>
>

I think EUMM is okay to support for simple Perl-only modules, but
things like "recommends" in Module::Build make it really attractive to
me as a CPAN developer. So I use simple EUMM modules where possible,
but otherwise if I need to have a slightly more complex build, I
switch to Build.PL

I think we should work to slowly phase out EUMM, since supporting it
is undoubtedly a nightmare (writing Makefiles and calling those?!).
M::B lets it all be done from Perl itself, and seems to be reaching a
point where it's mature/stable enough for real widespread use.

Plus being able to subclass it is tres cool.

Just my two cents.

Cheers,

Jonathan
(PAUSE: FREQUENCY)
0
jonathan
4/10/2009 4:19:13 PM
On Thu, 9 Apr 2009, Eric Wilhelm wrote:
> If you're installing today's code from the CPAN directly on outdated
> production machines, you're doing it wrong.  That's not a problem with
> M::B, and it is not a new user's immediate concern.

So, what *should* you install on outdated production machines? Because 
where I work, we've got a lot of them.  In fact, 'outdated' and 
'production' are practically synonyms.  And that's not going to change 
anytime soon.

--
David Fleck
david.fleck@mchsi.com

0
david
4/12/2009 12:18:03 PM
# from David Fleck
# on Sunday 12 April 2009 05:18:

>On Thu, 9 Apr 2009, Eric Wilhelm wrote:
>> If you're installing today's code from the CPAN directly on outdated
>> production machines, you're doing it wrong.     ^^^^^^^^
>
>So, what *should* you install on outdated production machines? Because
>where I work, we've got a lot of them.

There are plenty of options for doing it haphazardly, including simply 
installing a working cpan client.

But, if you're actively changing code on these machines, you really 
should have some sort of test/staging/deployment process to avoid 
surprise downtime and be able to rollback to the previous state.  This 
implies that you need some knowledge of how the sausage is made (or how 
to hire a consultant) and you'll probably also need to upgrade to a new 
ExtUtils::MakeMaker.  By the time you get all of those details sorted 
out, Module::Build is not a problem.

--Eric
-- 
Minimum wage help gives you minimum service.
--David Schomer
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
0
enobacon
4/12/2009 4:16:54 PM
On Thu, Apr 9, 2009 at 2:20 PM, Eric Wilhelm <enobacon@gmail.com> wrote:
> # from Jonathan Rockway
> # on Thursday 09 April 2009 13:30:
>
>>* On Thu, Apr 09 2009, Bill Ward wrote:
>>> How about you write a "how to manage Perl on your system" doc and
>>> get it into the core as a new perlxyz perldoc file then.
>>
>>That is a very good idea.
>>
>>Of course, the people that will update to a version of perl that
>>includes this doc probably won't need it ;)
>
> If everyone can get past the idea that something non-core is somehow
> unusable, a fine document already exists
>
> =A0http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practice=
s

It may be a best practice to maintain your own perl but having just
done this at work, it's a massive time sink. Our new platform at work
is an Ubuntu mod_perl system with 208 CPAN modules. We produced a .deb
for perl+modules and another for mod_perl but it took us several weeks
to do it and we had to learn a bunch about how to author for Debian.
It was painful and I don't recommend it for most people.

Some of the stuff that made it most annoying were CPAN modules that
had prompts or interacted with things outside the installation fake
root.

Josh
0
twists
4/13/2009 3:06:16 AM
# from Joshua ben Jore
# on Sunday 12 April 2009 20:06:

>> =A0http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practic=
es
>
>It may be a best practice to maintain your own perl but having just
>done this at work, it's a massive time sink. Our new platform at work
>is an Ubuntu mod_perl system with 208 CPAN modules. We produced a .deb
>for perl+modules and another for mod_perl

Only *one* .deb for perl and all of the modules?

>but it took us several weeks=20
>to do it and we had to learn a bunch about how to author for Debian.
>It was painful and I don't recommend it for most people.

You don't have to do it as Debian packages.  Simply installing from=20
source and then building a full set of modules has never taken me more=20
than a few hours.

=2D-Eric
=2D-=20
If the collapse of the Berlin Wall had taught us anything, it was that
socialism alone was not a sustainable economic model.
=2D-Robert Young
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------
0
enobacon
4/13/2009 6:20:16 AM
On Sun, Apr 12, 2009 at 11:20 PM, Eric Wilhelm <enobacon@gmail.com> wrote:
> # from Joshua ben Jore
> # on Sunday 12 April 2009 20:06:
>
>>> =A0http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practi=
ces
>>
>>It may be a best practice to maintain your own perl but having just
>>done this at work, it's a massive time sink. Our new platform at work
>>is an Ubuntu mod_perl system with 208 CPAN modules. We produced a .deb
>>for perl+modules and another for mod_perl
>
> Only *one* .deb for perl and all of the modules?

Yes. One deb. We've whittered about making more individual .debs but
it's so annoying to create them that I think we'll likely not change.
We don't go through this effort for Ruby+gems because currently we
think we can apt-get install it and gem install the rest without
conflicting since we deem it unlikely anything on the current system
actually cares super-hard about it.

>>but it took us several weeks
>>to do it and we had to learn a bunch about how to author for Debian.
>>It was painful and I don't recommend it for most people.
>
> You don't have to do it as Debian packages. =A0Simply installing from
> source and then building a full set of modules has never taken me more
> than a few hours.

/Now/ I can rebuild the set inside of half an hour which is /actually/
about 28 minutes too long. More highly annoying things are CPAN.pm
being unable to install from a set of local tarballs. I tried for a
bit to manufacture some small bits of program to create a local CPAN
repo and had some success but not enough that my sysadmin incorporated
it.

If I figure out a recipe that works nicely, I'll share it.

Josh
0
twists
4/13/2009 2:55:31 PM
* On Mon, Apr 13 2009, Joshua ben Jore wrote:
> /Now/ I can rebuild the set inside of half an hour which is /actually/
> about 28 minutes too long. More highly annoying things are CPAN.pm
> being unable to install from a set of local tarballs. I tried for a
> bit to manufacture some small bits of program to create a local CPAN
> repo and had some success but not enough that my sysadmin incorporated
> it.

Uh, CPAN::Mini and CPAN::Mini::Inject?

Andreas also maintains a list of CPAN module prompts and the "correct
answers".  You can use that to install modules without answering
questions for them.

(BTW, when I fix the perl build system, you will have to go way out of
your way to ask the user stupid questions.  No more "Are you sure you're
sure you're sure that you want to install the MANDATORY modules!!!!????
[y]")

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"
0
jon
4/13/2009 5:22:08 PM
>>>>> On Mon, 13 Apr 2009 07:55:31 -0700, Joshua ben Jore <twists@gmail.com> said:

  > More highly annoying things are CPAN.pm
  > being unable to install from a set of local tarballs. I tried for a
  > bit to manufacture some small bits of program to create a local CPAN
  > repo and had some success but not enough that my sysadmin incorporated
  > it.

  > If I figure out a recipe that works nicely, I'll share it.

You know how to untar a tarball and then you chdir into its directory.

And then you type

    cpan .

Let me know if it doesn't work for you, otherwise let me know where
you share it:)

-- 
andreas
0
andreas
4/13/2009 6:32:59 PM
On Mon, Apr 13, 2009 at 10:22 AM, Jonathan Rockway <jon@jrock.us> wrote:
> * On Mon, Apr 13 2009, Joshua ben Jore wrote:
>> /Now/ I can rebuild the set inside of half an hour which is /actually/
>> about 28 minutes too long. More highly annoying things are CPAN.pm
>> being unable to install from a set of local tarballs. I tried for a
>> bit to manufacture some small bits of program to create a local CPAN
>> repo and had some success but not enough that my sysadmin incorporated
>> it.
>
> Uh, CPAN::Mini and CPAN::Mini::Inject?

I wish I could recall why CPAN::Mini::Inject didn't seem appropriate.
I'll be redoing this thing anyway. I looked into Andreas'  distroprefs
but never found enough time to suss it. I have a blind spot toward
CPANPLUS and didn't even consider it.

Separately, I want to also solve this problem for ruby 1.8.6 + some gems. :-/

So, later, I guess I'll just report "Huzzah!" and that it all works
nicely when I remember to include all the good ideas already written.

Josh
0
twists
4/13/2009 9:17:31 PM
On Thu, Apr 09, 2009 at 04:37:09PM -0700, Eric Wilhelm wrote:

> Joking, right?  There's no need for "something in core" and it is 
> already "someplace appropriate".
> 
> The important attributes for this sort of information are that it is
> current, correct, and findable.
> 
>   http://www.google.com/search?q=perl+administration+best+practice

That's a very specific search string.  So while it is, I suppose,
findable, it's not *easily* findable.  If instead you search for "perl
installation and management, there's not a single perlfoundation page in
the first 100 results.  Likewise for "perl installation HOWTO".

And once you have found it, how is someone outside the community meant
to know that the authors know what they're talking about?

The reason to put doco like this in core is because a user can then
reasonably suppose that the authors really do know what they're talking
about, and that it was subjected to debate and peer review before
acceptance and promulgation.

And of course perldoc perladmin is rather less susceptible to casual
vandalism, spam, and misguided edits than a wiki is.

-- 
David Cantrell | A machine for turning tea into grumpiness

  "Cynical" is a word used by the naive to describe the experienced.
      George Hills, in uknot
0
david
4/14/2009 10:36:48 AM
On Sun, Apr 12, 2009 at 07:18:03AM -0500, David Fleck wrote:
> On Thu, 9 Apr 2009, Eric Wilhelm wrote:
> >If you're installing today's code from the CPAN directly on outdated
> >production machines, you're doing it wrong.  That's not a problem with
> >M::B, and it is not a new user's immediate concern.
> So, what *should* you install on outdated production machines? Because 
> where I work, we've got a lot of them.  In fact, 'outdated' and 
> 'production' are practically synonyms.  And that's not going to change 
> anytime soon.

Ideally, you'll be installing packages either from the vendor's package
repository or rolling your own.  Whether they be debs, rpms or plain old
tarballs isn't particularly important.  That way, you get known versions
of modules, instead of whatever the most recent version is on the CPAN
at the time you install on that particular machine, and so it's easy to
keep all your machines in sync - you don't have the problem of
installing Foo::Bar on one machine on Monday (and getting version 1.4)
and installing another machine with Foo::Bar 2.0 on Friday (which has
exciting API changes which your real-world (and therefore incomplete)
test suite doesn't catch).

But that's the ideal, and so all too often doesn't happen.

-- 
David Cantrell | Hero of the Information Age

    fdisk format reinstall, doo-dah, doo-dah;
    fdisk format reinstall, it's the Windows way
0
david
4/14/2009 12:03:49 PM
David Cantrell wrote:
> On Thu, Apr 09, 2009 at 04:37:09PM -0700, Eric Wilhelm wrote:
> 
>> Joking, right?  There's no need for "something in core" and it is 
>> already "someplace appropriate".
>>
>> The important attributes for this sort of information are that it is
>> current, correct, and findable.
>>
>>   http://www.google.com/search?q=perl+administration+best+practice
> 
> That's a very specific search string.  So while it is, I suppose,
> findable, it's not *easily* findable.  If instead you search for "perl
> installation and management, there's not a single perlfoundation page in
> the first 100 results.  Likewise for "perl installation HOWTO".
> 
> And once you have found it, how is someone outside the community meant
> to know that the authors know what they're talking about?
> 
> The reason to put doco like this in core is because a user can then
> reasonably suppose that the authors really do know what they're talking
> about, and that it was subjected to debate and peer review before
> acceptance and promulgation.
> 
> And of course perldoc perladmin is rather less susceptible to casual
> vandalism, spam, and misguided edits than a wiki is.
> 

+1 for perldoc perladmin.  Makes alot of sense and keeps with the rest
of Perl's documentation.  I would contribute to such a document.

-- 
Darian Anthony Patrick    <dap@darianpatrick.com>
=================================================
88FC 044D 5144 BD3A DAF8 FD9F 8C9E DF14 9AD3 4117
=================================================
* Signed and encrypted communications preferred.
0
dap
4/14/2009 3:39:04 PM
I'm responding in general to this thread, not to any specific message in it.

I created Module::Build simply because I thought there was a niche
that needed filling.  We needed a tool that would "make should-be-easy
things easy and make hard things possible" for the build & install
process.  It was clear EU::MM was never going to fill that niche.

Creating something to fill this niche DOES NOT MEAN that I wanted the
occupier of the existing niche to die.  To the contrary, there are
several major improvements to EU::MM that come directly from the M::B
project, most importantly META.yml and INSTALL_BASE.

If you want to keep using EU::MM then just keep using it.  Nobody,
least of all me, can reasonably criticize you for that unless it
causes someone else actual pain.  Just like nobody's going to fault
you if you edit your source code with Notepad.  At some level it's
just a question of taste and I'll be damned if I get in that argument.

 -Ken
0
kenahoo
4/14/2009 11:35:47 PM
[CCing Michael Schwern cos I'm not sure if he's on this list]

On Tue, Apr 14, 2009 at 11:39:04AM -0400, Darian Anthony Patrick wrote:
> David Cantrell wrote:
> > [re http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices]
> > ... once you have found it, how is someone outside the community meant
> > to know that the authors know what they're talking about?
> > 
> > The reason to put doco like this in core is because a user can then
> > reasonably suppose that the authors really do know what they're talking
> > about, and that it was subjected to debate and peer review before
> > acceptance and promulgation.
> > 
> > And of course perldoc perladmin is rather less susceptible to casual
> > vandalism, spam, and misguided edits than a wiki is.
> +1 for perldoc perladmin.  Makes alot of sense and keeps with the rest
> of Perl's documentation.  I would contribute to such a document.

Michael, how about PODdifying this and mumbling to p5p?  Or if you don't
have the time I could do it if that's OK with you.

-- 
David Cantrell | Minister for Arbitrary Justice

You can't judge a book by its cover, unless you're a religious nutcase
0
david
4/15/2009 2:04:02 PM
On Mon, Apr 13, 2009 at 02:17:31PM -0700, Joshua ben Jore wrote:
> On Mon, Apr 13, 2009 at 10:22 AM, Jonathan Rockway <jon@jrock.us> wrote:
> > * On Mon, Apr 13 2009, Joshua ben Jore wrote:
> >> /Now/ I can rebuild the set inside of half an hour which is /actually/
> >> about 28 minutes too long. More highly annoying things are CPAN.pm
> >> being unable to install from a set of local tarballs. I tried for a
> >> bit to manufacture some small bits of program to create a local CPAN
> >> repo and had some success but not enough that my sysadmin incorporated
> >> it.
> >
> > Uh, CPAN::Mini and CPAN::Mini::Inject?
> 
> I wish I could recall why CPAN::Mini::Inject didn't seem appropriate.
> I'll be redoing this thing anyway. I looked into Andreas'  distroprefs
> but never found enough time to suss it. I have a blind spot toward
> CPANPLUS and didn't even consider it.
> 
> Separately, I want to also solve this problem for ruby 1.8.6 + some gems. :-/
> 
> So, later, I guess I'll just report "Huzzah!" and that it all works
> nicely when I remember to include all the good ideas already written.

At work, we have one architecture running one OS*

We have perl built on a custom path, and all CPAN modules built for it. The
whole lot (the install tree including binaries) are checked into subversion.
We deploy from subversion. If we need to update an external module, we build
it once, by hand, then check in the new and changed files.

We have not bothered with burning time working out how to automate a build
process for external code. It's not worth it for us. We suspect that what we
have will be the most efficient way to scale to 2 or even 3 architectures.

(Note, our internal code is not XS, and is laid out in subversion correctly
for the live deployment. The odd bits of XS code are treated as external
CPAN modules)

Nicholas Clark

* Or at least, this will become true soon.
0
nick
4/16/2009 9:46:24 AM
Reply:

Similar Artilces:

Is the "Discussions" module the same as "Forum" module?
My fresh install of DNN has several modules, including a "Forum" module.  The online tour mentions a "Discussions" module, but not a forum one. Are these the same?  If so, why does my Forum module not have a "Configuration" item in the Module Actions Menu?  I can't find a way to configure the thing, or any of the other modules for  that matter.I have the same problem with the Photo Gallery module - there's no "configuration" menu item; there's a Module Settings item, but that only lets me configure permissions, header, footer, colors, etc. Any ideas?  I'm loggin...

"My Modules" module
Our users want to be able to customise the front page by being able to choose to add to the front page any module they have permission to view.  Are there any products which supports this?      Jonathan Palmer not too sure what you actually want but create a role called contentadmin create a user and allocate him to this role. then edit the home page and give authority to edit the page to this role now when that user logs in they will get the tab section on the top of the page and can add any modules available to that page only. They can also edit t...

Questions regarding use: "optional" modules, and "refreshing" modules
Folks, I've run into a couple of issues with use and was hoping someone could help me come up with a solution. First, I use a specific module in a work environment to set some global variables. I want to re-use my code in another environment which doesn't have the specific configuration module. I don't want to have to keep two separate copies of the code. What I currently use in the work environment is of the format: use lib '/path/to/work/modules'; use Prefs; my $config =3D Prefs->new(); my $param1 =3D $config->get("PARAM1"); I'd l...

"Random Module" Module
Hi, is there something like a "random module" module available? I mean, that with a (re)load of the current page one gets a ramdomly chosen module (text 1, alternative text2, alternative text3 for example). It should work with the standard HTML-module, but also with the NewsArticle, TextLayout, Multi Page Content modules. Cheers, DocHoliday BTW: is it just me who is experiencing that one cannot use the cursor keys inside the message edit textbox of ASP.NET forums?MCSA/MCSE on W2K3, artless DNN operator...

Re: Cpan Ratings (Was: Future of the "Module List")
Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? Is it the author's 'Perlish' coding style, in which he places statement-ending semicolons at the start of the line? Or something else? jimk James Keenan writes: > Pardon my ignorance, but ... > > What is the 'default phone-home behavior' in the Makefile.PL's about > which Randal was complaining? The author wished to keep track of how widely his modules were used -- at least partially as mot...

My "own" modules
If I have an account with a private CGI-BIN that allows me to use my own modules (meaning other modules they haven't installed), how do I tell my scripts how to use those modules? Ex: I upload HTML::Template to CGI-BIN/modules How do I tell my scripts to use it? On Mon, 21 Apr 2003 at 16:32, Bob X opined: BX:If I have an account with a private CGI-BIN that allows me to use my own BX:modules (meaning other modules they haven't installed), how do I tell my BX:scripts how to use those modules? BX: BX:Ex: I upload HTML::Template to CGI-BIN/modules BX: BX:How do I t...

Is there a "workflow" or "document control" module for DNN2?
Is there a "workflow" or "document control" module for DNN2? As a collaborative tool, this type of module seems like a no brainer. There was a Document Version Control for pre-DNN2, but that hasn't been ported over and, quite frankly, I don't know if it was any good or not. Please let me know if you know of one for free or purchase, or if you have a work in progress. Thanks! Eric Just posing this question again as I'm running into dead ends. Any feedback would be appreciated. Eric We are also very keen to use such a module. At www.dotnetnuke.de there ...

Searching "Reminder" and "newest Content" Modules
Hello, I'm looking for some Modules. One should be a helper to Admins. I imagine a kind of list with content that wasn't be modificated for a longer (adjustable) time. With this overview an Admin is able to see outdated content and could go for a review. The other should be like a little toplist of the newest content in a portal. A litte infobox shows a user the most actual content. Does anybody knows such modules? Regards Marcus All the info you need for a What's New module is already in the Search Items table and you can display it using existing features of DNN3. Jus...

"Edit Module Definitions" and "Add Definition"
Hi.I like to know what is the function of Add Definition in the "Edit Module Definitios". Where I can use this definitio, it's is posible to select different definitions of one module to display in differents pages?RegardsAlejandro    It's used when you manually add a DNN module and it's components. This is the way you test/debug a module (i.e. before you have to create a .dnn file) e.g. you can see it described here (scroll down a little) http://dnnjungle.vmasanas.net/Development/HelloWorldTutorialv3/tabid/117/Default.aspx#85Cathal But how do you get to select controls fr...

Adding a "HAL" sub-module under "Core"
Hi, I would like to propose adding a HAL sub-module under "Core" that would be like this: Name: HAL Description: Hardware Abstraction Layer Owner: Chris Jones Peers: Mounir Lamouri and Justin Lebar Source Dirs: hal/ Bugzilla Components: Core :: Hardware Abstraction Layer (HAL) This has been previously discussed with Chris and Justin and they agreed with the description. HAL isn't a big and complex piece of code so we spent a long time without a module for it but people tend to touch it a lot those days and don't always realize this is about abstraction. ...

Failed to load module "pk-gtk-module"
I've reinstalled openSUSE 11.1 x86_64 Gnome on my machine using the NET-install CD. After that I've run 'zypper up'. Any solution for the following issue, that arrieves when I try to start applications Code: -------------------- Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory. -------------------- -- terjejh ------------------------------------------------------------------------ I bump this one againg, as I still get this error message. Any id...

my DNN module ignore the "Display Module On All Pages"
hi, my C# module doesn't appear on all tabs : i have checked the ""Display Module On All Pages" checkbox in the Advanced Settings of the module Settings. Has anybody ideas of what could be the cause? How does the Display Module On All Pages works? Thanks, alexisdv I am not very sure, how & why it works, but I have noticed that if you add any page after the Module, it does not display on that page. Try this 1. Go to the Module Setting fo the Module that you wish to show on all pages 2. Uncheck the the "Display Module On All Pages" CheckBo...

cannot find "Module Installation" after clicking "Configure" icon
I've been working through the Linux OES Lab setup on a test server according to the Doc. of "LAB GUIDE FOR OES SP2 LINUX". Everything seemed to work well with the installation until "4.3 Installing the iFolder 3.x iManager Plug-in" I cannot find "Module Installation" menu item after clicking "Configure" icon. Also it display nothing after clicking "Roles and Tasks" icon. What is wrong? Should I check my eDirectory setting ? Or had I put the wrong value "In the iFolder Admin DN field, type cn=admin.o=COMPANY."...

cannot find "Module Installation" after clicking "Configure" icon
I've been working through the Linux OES Lab setup on a test server according to the Doc. of "LAB GUIDE FOR OES SP2 LINUX". Everything seemed to work well with the installation until "4.3 Installing the iFolder 3.x iManager Plug-in" I cannot find "Module Installation" menu item after clicking "Configure" icon. Also it display nothing after clicking "Roles and Tasks" icon. What is wrong? Should I check my eDirectory setting ? Or had I put the wrong value "In the iFolder Admin DN field, type cn=admin.o=COMPANY." ?...

Web resources about - "PBP Module Recommendation Commentary" and recent CPAN ratings spammings - perl.module-authors

Resources last updated: 12/20/2015 4:15:20 PM