Re: a lot of controversy about Module::Build
# 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 ---
Re: RFC: Yet Another Excel Writer..
On Wed, Apr 08, 2009 at 02:58:43PM -0700, Bill Ward wrote: I think ::Simple is probably the most standard way of doing that. I'm not aware of any ::Easy modules. FWIW, ... mysql select distinct module from modules where module like '%::Easy'; +-+ | module | +-+ | Algorithm::Evolutionary::Op::Easy | | Authen::Krb5::Easy | | Bone::Easy | | Class::Easy | | Config::Easy| | Curl::easy | | Daemon::Easy| | Date::DateTime::Easy| | DateTime::Easy | | DateTimeX::Easy | | DBI::Easy | | DBIx::Easy | | Egg::Plugin::BackUP::Easy | | Egg::Plugin::DBI::Easy | | Exporter::Easy | | Frontier::Client::Easy | | Getopt::Easy| | Graph::Easy | | IO::Easy| | IO::Pty::Easy | | Lingua::EN::Numbers::Easy | | Log::Easy | | Logic::Easy | | Mail::Summary::Tools::ArchiveLink::Easy | | MLDBM::Easy | | MooseX::Log::Log4perl::Easy | | MySQL::Easy | | Net::Pcap::Easy | | Penguin::Easy | | Project::Easy | | RDF::AllegroGraph::Easy | | Test::Easy | | Text::Editor::Easy | | Tie::Hash::Easy | | Tie::IxHash::Easy | | Tie::Scalar::Easy | | TM::Easy| | Win32::GUIRobot::Easy | | WWW::Curl::Easy | | XML::Easy | | XML::LibXSLT::Easy | +-+ 41 rows in set (9.89 sec) -- David Cantrell | Hero of the Information Age Irregular English: ladies glow; gentlemen perspire; brutes, oafs and athletes sweat
Re: a lot of silliness about Module::Build
- Original Message From: Andy Lester a...@petdance.com Don't know. Just saying why I have never switched: Because I've never heard a compelling enough reason to make the time investment. Exactly! Thank you, Andy++ Me? I use M::B for most of my modules. Generally 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. I have no idea why people debate this. MB and MI are clearly superior to EU::MM [1], but so what? Don't need 'em? Don't use 'em. I'm sorry. What were people saying again? Cheers, Ovid 1. 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 system with an unknown version of make have different opinions, though. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: a lot of controversy about Module::Build
# 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? 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?
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. ... If 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. 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.
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.)
And for those who would recommend M::I, would you also explain the
pitfalls of that, or simply leave it as what you don't know yet won't
hurt you yet?
--Eric
--
perl -e 'srand; print join( ,sort({rand() 0.5}
qw(sometimes it is important to be consistent)));'
---
http://scratchcomputing.com
---
Re: a lot of controversy about Module::Build
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
Re: a lot of controversy about Module::Build
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
Re: a lot of controversy about Module::Build
# from David Cantrell # on Thursday 09 April 2009 10:01: 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? ... 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 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. Sure, you'll need to brief a new hire on your deployment mechanism and its caveats, but that's true at any business. --Eric -- Entia non sunt multiplicanda praeter necessitatem. --Occam's Razor --- http://scratchcomputing.com ---
Re: a lot of controversy about Module::Build
* 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. ... If 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 your 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? 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 = another = perl = hacker = if $,=$
Re: a lot of controversy about Module::Build
On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@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...
Re: a lot of controversy about Module::Build
* On Thu, Apr 09 2009, Bill Ward wrote: On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@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. -- print just = another = perl = hacker = if $,=$
Re: a lot of controversy about Module::Build
On Thu, Apr 9, 2009 at 12:10 PM, Jonathan Rockway j...@jrock.us wrote: * On Thu, Apr 09 2009, Bill Ward wrote: On Thu, Apr 9, 2009 at 11:26 AM, Jonathan Rockway j...@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.
Re: managing your perl
# 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 ---
Re: managing your perl
# 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 unusable, a fine document already exists http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices Ok. Now 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 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 --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 ---
Re: managing your perl
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 enoba...@gmail.com wrote: Joking, right? There's no need for something in core and it is already someplace appropriate. -- Curtis Jewell swords...@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 swords...@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]
Re: a lot of controversy about Module::Build
Jonathan Rockway j...@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.
