Re: managing your perl
[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
Re: managing your perl
On Mon, 13 Apr 2009 07:55:31 -0700, Joshua ben Jore twi...@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
Re: managing your perl
# from Joshua ben Jore # on Sunday 12 April 2009 20:06: http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices 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 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 source and then building a full set of modules has never taken me more than a few hours. --Eric -- If the collapse of the Berlin Wall had taught us anything, it was that socialism alone was not a sustainable economic model. --Robert Young --- http://scratchcomputing.com ---
Re: managing your perl
On Sun, Apr 12, 2009 at 11:20 PM, Eric Wilhelm enoba...@gmail.com wrote: # from Joshua ben Jore # on Sunday 12 April 2009 20:06: http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices 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. Simply 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
Re: managing your perl
* 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 $,=$
Re: managing your perl
On Mon, Apr 13, 2009 at 10:22 AM, Jonathan Rockway j...@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
Re: managing your perl
On Thu, Apr 9, 2009 at 2:20 PM, Eric Wilhelm enoba...@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 http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices 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
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]
