Modern Perl Books for modern Perl programming — comments

Re: Upgrading User Password Hashes in Place — From: chromatic

2012-02-22T18:52:15Z

The client doesn't send hashed passwords—or if the client sends a hashed password, you have to hash it again on the server.

Eavesdropping and securing stored passwords are different problems.

Re: Upgrading User Password Hashes in Place — From: Sue D. Nymme

2012-02-21T16:44:30Z

Here's something that has always bugged me. I'm sure it must be a solved problem, but I have been unsuccessful in finding the proper practice. It's a little bit of a tangent, but I hope you'll indulge me.

So your user sets his password. The client hashes the password, and sends it to your server. You store the user ID, hashed password, and maybe the salt value. Haha, you think, I'm safe from hackers now.

Haven't you just substituted hashed-passwords for passwords?

If someone hacks into your database and grabs user IDs, salts, and hashed-passwords, can't they just use those to log in? Their client, instead of hashing a plaintext password, sends the hashed password. Or say you don't get hacked, and someone eavesdrops on a user's unencrypted internet conversation. He'd get the hashed password and be able to log in with that, no?

If the solution is "force https" or "have the client encrypt a packet containing the userid & hashed password", then isn't hashing the password redundant?

Re: Upgrading User Password Hashes in Place — From: chromatic

2012-02-21T15:34:55Z

You're right. I found and fixed a bug in the actual code, and your approach made that easier.

I thought about doing things the right way when I first wrote the code, but somehow convinced myself that it wasn't worth the additional effort. Perhaps I hadn't realized then that the prefix approach would work.

Re: Upgrading User Password Hashes in Place — From: notbenh.myopenid.com

2012-02-21T08:32:07Z

The only thing that I can think of is why always do the old check first? I know that this is 'temp' code but it seems that if you can 'find' new passwords by prefix then you could just use that do decide what hash to match and then you would only do the hash once in the case of 'updated' passwords.

Re: The Values and Costs of Automation — From: chromatic

2012-02-20T20:00:45Z

I use the Module::Build plugin, and even if I didn't, I don't have to work with MakeMaker directly, but point well taken.

Re: The Values and Costs of Automation — From: skaufman.myopenid.com

2012-02-20T02:34:22Z

Dzil's default minting profile uses the @Basic plugin bundle
which includes Dist::Zilla::Plugin::MakeMaker - "Dist::Zilla::Plugin::MakeMaker - build a Makefile.PL that uses ExtUtils::MakeMaker."

You're hating (however mildly) on something that dzil's using behind several layers of abstraction.

Re: Install Distros Under Development Locally — From: chromatic

2012-02-17T08:00:03Z

I will now! I'd never thought to read the documentation for Dist::Zilla::App::Command::install.

Re: Install Distros Under Development Locally — From: rjbs.manxome.org

2012-02-17T03:04:06Z

dzil will probably switch to defaulting to cpanm once I provide a useful mechanism for stating your cpan client pref more globally in the future

i.e., "someday beyond tomorrow"

Re: Install Distros Under Development Locally — From: Jesse

2012-02-17T01:52:24Z

"dzil install" does have an "--install-command" option, which allows you to specify an alternative command to use for installation - "dzil install --install-command 'cpanm .'" would be pretty much equivalent to your alias.

Re: Install Distros Under Development Locally — From: chris.prather.org

2012-02-17T01:46:50Z

Why not just use the built in dzil install?

alias dzinstall='dzil install --install-command "cpanm ."'

Re: Experts versus Novices — From: http://www.butteredham.com/blog/

2012-02-15T00:07:02Z

"The tricky part is when someone's obviously doing something the wrong way [...]"

And also finding the fine line between wrong in the sense of "broken and will not work," and wrong in the sense of "a very bad way to do it that should be discouraged, even though it'll work."

The other day I answered a question on PerlMonks, where a guy was looking for lines in file1 that matched lines from another file. He was doing it with nested loops, looping through file1, and then for each line from that file, looping through file2 and comparing each line. His question wasn't about whether this was a good idea, but regarding something else that was actually broken in the code. His nested loops would work; they were just a horrible way to do it.

Any mildly experienced Perl programmer looks at that problem and instantly thinks, "make a hash from file2 and then loop through file1 checking for the existence of keys in the hash." That algorithm is so superior, and perl's hashes so suited to it, that it's automatic. I felt a duty to explain that to him, but since his question wasn't actually, "Tell me what a lame noob I am at Perl," I put it as gently as possible, like, "Here's a way to do it that's much more Perlish and will work better for you."

It does get frustrating to help people when half your answers consist of, "Let Perl tell you the problem by using strict, warnings, and error checking." It is painful to keep seeing code like 'open(FILE,"){'. But answering the same basic questions over and over is part of teaching, whether you're doing it on a web forum or in a classroom. I wrote code like that too, when I was getting started. I like to think I got better.

To some extent, I think we're victims of Perl's success and staying power. Perl newbies are still turning out 1995-style code because the books and tutorials written back then were so good that people are still learning from them! If (God forbid) people are still coding in PHP 17 years from now, I doubt they'll be learning from the mess of code snippets that make up php.net. But can you learn to be a productive Perl coder from the camel book today? Absolutely.

Re: The Values and Costs of Automation — From: chromatic

2012-02-14T18:51:40Z

Exactly. To put another way, good automations compound.

You see this also with the Unix command line.

Re: The Values and Costs of Automation — From: dagolden.com

2012-02-14T03:27:54Z

I think part of the power of Dist::Zilla that is overlooked or underappreciated by novice users is the plugin architecture and particularly user-specific plugin bundles.

For example, after getting about six different "you have a spelling error" bug reports sent back upstream to me from the (awesome) Debian Perl team, I decided that I needed to start spell checking my Pod. I added a spelling plugin [1] (that someone else wrote) to my plugin bundle, tweaked the bundle configuration attributes to let me pass through multiple stop words, and then every single distribution I release has spell checking henceforth.

It's not about whether you can do something with Dist::Zilla versus other tools, it's about whether you want to have Dist::Zilla give you a well-architected way to manage all your distributions similarly with minimal effort (and to customize them when you need to) or whether you want to manage them all separately (or whether you want to roll your own system for doing some or all of what Dist::Zilla does).

The time savings comes not from converting any individual distribution, but from the cumulative compound effect of using Dist::Zilla to automate more and more things and more and more distributions over time.

[1] Dist::Zilla::Plugin::Test::PodSpelling

Re: Templating with Widgets, Not Primitives — From: chromatic

2012-02-13T23:41:00Z

I tried CSS::LESSp on a project and it didn't handle all of the Less I needed. I didn't spend much time debugging it. (Did I mention I hate writing, maintaining, and patching parsers?)

Re: The Values and Costs of Automation — From: http://petdance.com/openid/

2012-02-13T16:06:25Z

Automating a task is only worthwhile when the benefit of automation outweighs the cost of doing so, OR when publishing that automation to the world will provide benefits for others as well.

When I created Module::Starter, it was partly to save myself the time and hassle of cut & paste module starting, but also to let others avoid it as well.

It's also worth noting that the benefits of automation aren't always based on time. Code quality is a huge benefit, and my understanding of Dist::Zilla is that it takes care of all those little things that we tend to forget on release, eliminating the human error factors.

DRY (Don't Repeat Yourself) is an important principle because it reduces the chances of error. In this respect, it applies to repeated tasks as well.

Re: Templating with Widgets, Not Primitives — From: yanick.myopenid.com

2012-02-13T13:00:04Z

There is, incidentally, also a Perl port of LESS: http://search.cpan.org/~drinchev/CSS-LESSp-0.86/ Its implementation has a few... scary edges, but at least they are Perl-scary, as opposed to Node.js-terrifying.

And on a totally sympathetic unrelated note, a segment of my latest book does involve skydiving, surfing on the lava of an erupting volcano, and dealing with gigantic tentacled land sharks... So I guess, whatever you do, don't visit Morvak 13. You won't like it. :-)

Re: The Values and Costs of Automation — From: jnareb.myopenid.com

2012-02-13T11:51:58Z

First, what to use if not EUMM if Perl code is fragment of larger project (in C mainly) that uses Makefile?

Second, Dist::Zilla has quite heavy dependencies... though Pod::Weaver looks like fun. Things like automatically testing synopsis etc.

Re: Templating with Widgets, Not Primitives — From: http://www.bsdhosting.co.za/index.html

2012-02-11T00:29:20Z

Template::Declare seems a good fit for that style, something like:



template newsletter => sub {

 row {

       maincontent {

         show( 'components/content/home_text' );

      };

      sideblock { show( 'components/forms/login_box' ); };

      sideblock { show( 'components/boxes/top_recommendation' ); };

      sideblock { show( 'components/content/newsletter_text' );  };

     };

};

Template::Declare->show('newsletter');

Each of login_box, top_recommendation and newsletter_text being templates defined similarly, using TD's declarative template syntax.

Re: A Practical Use for Macros in Perl — From: Leon Timmermans

2012-02-07T01:01:08Z

I once wrote Scalar::Andand for this purpose, though I consider it a horrible hack and don't really recommend it to anyone.

Re: A Practical Use for Macros in Perl — From: http://openid.tobyinkster.co.uk/tobyink

2012-02-06T21:37:14Z

Just uploaded a bit of sugar to CPAN.

use PerlX::Perform;
...

while (my $stock = $stock_rs->next)

{

    perform { $txn->add($_) } wherever $self->analyze_pe($stock);

    perform { $txn->add($_) } wherever $self->analyze_cash_yield($stock);

}

It assumes that analyze_pe and analyze_cash_yield perform undef or the empty list for failure. If they return a false but defined value, then the perform {...} block is still triggered.

Re: A Practical Use for Macros in Perl — From: https://me.yahoo.com/mithaldu#29f3a

2012-02-06T11:25:09Z

Well, if that solution is too clever, this works too:

while ( my $stock = $stock_rs->next ) {
ADD_TXN_WITH( $self, analyze_pe => $stock, $stock_txn );
ADD_TXN_WITH( $self, analyze_cash_yield => $stock, $analysis_txn );
}

sub ADD_TXN_WITH {
my ( $self, $method, $stock, $txn ) = @_;

my $result = $self->$method( $stock );
$txn->add( $result ) if $result;

return;
}

Re: A Practical Use for Macros in Perl — From: Aristotle Pagaltzis

2012-02-06T09:49:33Z

The problem here is ultimately that the declaration does not take effect until the end of the statement. Sometimes that’s an incredibly useful property but I have also often found it a hindrance. Consider:

my $pe_update;
$pe_update = $self->analyze_pe( $stock ) and $stock_txn->add( $pe_update );

You can do away with the declaration, but weaving in the conditional then requires ugliness:

$stock_txn->add( $_ ) for grep { $_ } $self->analyze_pe( $stock );

If we could have in Perl 5 what Perl 6 allows, namely combining two modifiers as long as one is a loop and one a conditional, then it could even look pretty nice:

$stock_txn->add( $_ ) if $_ for $self->analyze_pe( $stock );

Of course object-heads will shake their heads. If analyze_foo returned an object with an add_to method you could just write this:

$self->analyze_pe( $stock )->add_to( $stock_tnx );

If the analyze_foo methods return a null class instance for a thumbs-down result then polymorphism sorts it all out for you, as Kay intended.

In the meantime, people who know monads will be chuckling and shaking their heads, barely perceptibly.

Re: A Practical Use for Macros in Perl — From: chromatic

2012-02-06T06:27:10Z

I thought about your suggestion while I was coding, but it didn't seem nicer to me. I like and use transient data structures often in situations like this, but it's more indirection than I usually want to maintain.

Your point about the abstraction of names without the overhead of dispatch is well taken.

Re: A Practical Use for Macros in Perl — From: https://me.yahoo.com/mithaldu#29f3a

2012-02-06T00:47:01Z

You can have your suggested macro syntax already and have it be even nicer:

while ( my $stock = $stock_rs->next ) {
$self->try_add( %$_, $stock ) for ( { pe => $stock_txn }, { cash_yield => $analysis_txn } );
}

sub try_add {
my ( $self, $method, $txn, $stock ) = @_;

$method = "analyze_$method";
my $result = $self->$method( $stock );
$txn->add( $result ) if $result;

return;
}

That's absolutely not what Perl needs macros for, since it already has enough expressiveness to do almost anything they could do. However, that doesn't mean there's no need for them. In fact, there is a very pressing need:

Performance

In certain situations Perl's function call overhead can become a liability and necessitate code like this:

http://dwarvis.googlecode.com/svn/trunk/lifevis/Lifevis/Viewer.pm

In a number of places there i would've liked to not have for loops nested in for loops stretching over more than 100 lines. I would've loved to have specific actions separated into subroutines and named sensibly. However i was forced to dissolve subs into those loops because calling them was too much of a performance drain.

This is a perfect case where macros would've helped keep the code speedy, while also making it readable.

Re: A Practical Use for Macros in Perl — From: http://openid.tobyinkster.co.uk/tobyink

2012-02-04T14:54:59Z

How about so called "bare loops" with next?

while (my $stock = $stock_rs->next)
{
    PE: { $txn->add( $self->analyze_pe($stock)         or next ) }
    CY: { $txn->add( $self->analyze_cash_yield($stock) or next ) }
}

Here, if analyze_pe or analyze_cash_yield return false, next is triggered before add thus jumping out of the bare loop before add ever happens.

Re: A Practical Use for Macros in Perl — From: cowens.myopenid.com

2012-02-04T12:16:08Z

I may be dense, but to me this does look like a case of needing macros, but rather a case of the add_txn method force checking on the calling code. If we look at what you consider the clearest code, we can see that what you really want is for add_txn to ignore undefs (or false values, but I suspect they are effectively the same here). Why not modify add_txn to reject undefs? Is there ever a case you want to add an undef to a transaction?

Re: A Practical Use for Macros in Perl — From: rcaputo.myopenid.com

2012-02-03T23:36:10Z

Now that I've actually read what you wrote earlier about macros, Filter::Template isn't the type you're looking for. It is one way to solve the immediate problem here, though.

Re: A Practical Use for Macros in Perl — From: rcaputo.myopenid.com

2012-02-03T23:32:03Z

Filter::Template on CPAN allows you to do something like this:

use warnings;
use strict;

sub Filter::Template::DEBUG () { 1 }

use Filter::Template;

template ADD_TXN_WITH (analyze_object, analyze_method, analyze_stock, txn_obj) {

  {

    my $result = analyze_object->analyze_method( analyze_stock );

    txn_obj->add( $result ) unless $result;

  }

}

{% ADD_TXN_WITH $self, analyze_pe, $stock, $stock_txn %}

{% ADD_TXN_WITH $self, analyze_cash_yield, $stock, $analysis_txn %}

A source filter registers template definitions and expands invocations inline before the program is compiled. All the usual source-filter caveats apply until someone submits a patch to use PPI, a B module, or something even better.

#line directives preserve the sanity of errors and warnings. Because DEBUG is set, the example above generates the output below. You may need to widen your browser or shrink your font to see the full effect.

   6 |: 
   7 D: # template ADD_TXN_WITH (analyze_object, analyze_method, analyze_stock, txn_obj) {
   8 M: # mac 4:   {
   9 M: # mac 4:     my $result = analyze_object->analyze_method( analyze_stock );
  10 M: # mac 4:     txn_obj->add( $result ) unless $result;
  11 M: # mac 4:   }
  12 M: # mac 4: }
  13 |: 
  14 S: # line 14 "template ADD_TXN_WITH (defined in filter-template.pl at line 8) invoked from filter-template.pl"
  14 S: {
  14 S: # line 14 "template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl"
  14 S:     my $result = $self->analyze_pe( $stock );
  14 S: # line 14 "template ADD_TXN_WITH (defined in filter-template.pl at line 10) invoked from filter-template.pl"
  14 S:     $stock_txn->add( $result ) unless $result;
  14 S: # line 14 "template ADD_TXN_WITH (defined in filter-template.pl at line 11) invoked from filter-template.pl"
  14 S:   }
  14 S: # line 15 "filter-template.pl"
  15 S: # line 15 "template ADD_TXN_WITH (defined in filter-template.pl at line 8) invoked from filter-template.pl"
  15 S: {
  15 S: # line 15 "template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl"
  15 S:     my $result = $self->analyze_cash_yield( $stock );
  15 S: # line 15 "template ADD_TXN_WITH (defined in filter-template.pl at line 10) invoked from filter-template.pl"
  15 S:     $analysis_txn->add( $result ) unless $result;
  15 S: # line 15 "template ADD_TXN_WITH (defined in filter-template.pl at line 11) invoked from filter-template.pl"
  15 S:   }
  15 S: # line 16 "filter-template.pl"
Global symbol "$self" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl line 14.
Global symbol "$stock" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl line 14.
Global symbol "$stock_txn" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 10) invoked from filter-template.pl line 14.
Global symbol "$self" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl line 15.
Global symbol "$stock" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 9) invoked from filter-template.pl line 15.
Global symbol "$analysis_txn" requires explicit package name at template ADD_TXN_WITH (defined in filter-template.pl at line 10) invoked from filter-template.pl line 15.
Execution of filter-template.pl aborted due to compilation errors.

Re: Why I Run Tests on Install — From: szabgab.com

2012-02-01T06:11:14Z

tobyink, Leon, that sounds nice. I am not sure it needs to be solved for the general case. It can be a strong recommendation that tests should not assume any file present outside of t/ or that tests should have a mode to 'test against installed versions'.

Then some CPAN Testers could setup smokers that would test each module that way too and start reporting which ones fail in that case.

Re: Why I Run Tests on Install — From: Leon Timmermans

2012-02-01T00:08:58Z

A solution for that is on my todo list for the QA hackathon, but I can't make any promises. In particular, the problem tobyink pointed out is tricky to solve, and probably requires metafile support or some such.

Re: Why I Run Tests on Install — From: http://openid.tobyinkster.co.uk/tobyink

2012-01-31T22:53:58Z

App::Reprove is my solution for testing an already-installed module. You type:

reprove Foo::Bar

... at the command line, it tries to find the appropriate distribution on CPAN, downloads the MANIFEST, greps it for files matching m{^t/}, downloads those into a temporary directory and points App::Prove in their direction.

It's not perfect - some distributions may rely on files outside "t" to pass the tests. And sometimes it may need additional hints to find the correct distribution (e.g. version, cpanid). But it seems to work in many cases.

Re: Why I Run Tests on Install — From: perlpilot.myopenid.com

2012-01-31T20:47:50Z

Not running tests on installation has the nasty side effect of an end user encountering failure at some indeterminate time in the future and having very little clue about the nature of the failure. Testing on install at least lets whoever is doing the installation know up-front that there may be problems and by requiring those tests, a human being is needed to make the call on whether or not to force the installation. This is a good thing.

Though, I wonder if there is some value in making tests an installable component and providing a tool to run those tests? At least then, the end users would have another tool to help them diagnose problems they may encounter (like when a BOFH does a force install because he's too lazy to figure out why some tests are failing). I haven't imagined very far on this, but it would look something like this:

    User: I'm having trouble with module XYZ
    Us:   Have you tried running the test suite for that module?  
          Type "test_module XYZ" to do so.
    User: Ah, no.  Let me try that
          ... time passes ...
    User: It fails test 53.
    Us:   Run that test individually with "test_module XYZ 53" to see what's up.
    User: Ok.
    User: Ah, it's failing because an external XML lib isn't installed.
    Us:   So, you need to install that or have your sysadmin install it, 
          then you can run the tests again to make sure.
    User: thanks!

Re: Avoiding The Vendor Perl Fad Diet — From: chromatic

2012-01-31T18:41:05Z

How does Java being a world of suck make it acceptable for Perl to be a world of suck?

Please don't put words in my mouth.

Deploying software with dependencies takes effort. You can do that work by forbidding dependencies, by managing dependencies for each application individually, or by managing dependencies for all applications centrally. I prefer the second, and you prefer the latter.

I've worked in both situations in multiple languages: the most recent time the central approach bit me was a large Java project, where the Java ecosystem prefers application-as-big-blob-in-WAR approach but the system administrators required the build process to pull vetted dependencies and versions from a central JAR repository.

I grant you that this is not an example of the best way to manage centralized dependencies, but it was an act of root to get information on how to use the repository, let alone get a new version of a library in there. Don't even ask about how to get a new library installed.

The worst part was when one application relied on a library version incompatible with a newer version which contained important bugfixes our application needed.

I admit it's possible to create and maintain a centralized repository while minimizing these problems, but I've experienced its drawbacks enough that I'm leery.

Re: Avoiding The Vendor Perl Fad Diet — From: http://openid.aliz.es/sysop

2012-01-31T03:33:51Z

I don't understand. How does Java being a world of suck make it acceptable for Perl to be a world of suck? What the hell does Java's horrendous binary-distribution addiction have to do with this discussion? I'm talking about packaging cpan, not downloading random precompiled XS modules.

The reason you've only seen this work in trivial situations is that not many organizations have the resources to devote enough operations time to solving the problem correctly. We do, and so we have. The first thing we do is break out all of the modules from the vanilla distribution, for exactly the reasons I specified, and then put everything into RPMs for distribution.

We also have a pretty comprehensive testing platform. The procedure, simplified for this comment, is: update local cpan mirror, build all the modules we use (and their dependencies), fix build problems, rerun packaging scripts, upload to channel for distribution. It's taken us a while to get it robust, and redhat's new packaging decision would enable us to skip the tedious breakout of the core packages, etc. Periodically (I shoot for about once a month, or when it's requested by the devs, whichever comes first) we update the local cpan mirror and test the new cpan stuff, the software we use, and the software we write, and make sure it all works before we distribute it to the grids and the clusters.

It's nice to be able to upgrade the interpreter without rebuilding every single module it comes with. It's nice to be able to upgrade a leaf module all the way back to root perl without having to monkey with idiotic dependency listings. And our developers like having a perl installation they can rely on and expand.

Semirelated: BSDPan is one of the greatest tools for module distribution I've ever worked with, and I hope to god that one day my HPC work and BSDPan have a chance to come together. I could probably cut back to a four-day work week.

Re: Speed up Perlbrew with Test Parallelism — From: jonswar.myopenid.com

2012-01-30T13:40:41Z

You can also pass "--notest" to both perlbrew and cpanm to skip tests, which is even faster than running them in parallel. :)

Honestly, with the vastness of the CPAN Testers network, it makes no sense for the vast majority of users to run Perl and CPAN tests on their own systems.

The default running of CPAN tests in particular causes great harm by causing failures up the dependency chain, failures that are meaningless to most users yet cause them to back away from installing modules with multiple dependencies such as Moose and Catalyst. It encourages module developers to reduce or eliminate dependencies, aka reinvent the wheel.

--notest is always set on my system, and I wish it was the default for perlbrew and cpanm.

Re: Speed up Perlbrew with Test Parallelism — From: autarch.urth.org

2012-01-28T05:24:25Z

You can also pass "-j N" to perlbrew directly when building a new perl. This will actually cause it to run make in parallel, which affects more than just tests.

Re: Avoiding The Vendor Perl Fad Diet — From: andreasvoegele.com

2012-01-27T07:51:35Z

I use Perl amongst other things because it is usually already there no matter whether the operating system is Linux, BSD, Solaris, HP-UX or AIX. Sometimes system administrators refuse to install other scripting languages or rather any other package. If Perl will no longer be provided completely with a set of modules one can depend on, the advantage of being already installed will be gone. Granted, working with the pre-installed Perl is often unpleasant and chances that Python and Ruby are also available is nowadays much higher anyway, but Perl still has got an advantage.

Re: Avoiding The Vendor Perl Fad Diet — From: chromatic

2012-01-26T16:37:06Z

Have you ever deployed a Java application? I have. See also WAR files and Maven and Subversion repositories full of JARs and....

I'd like what you suggest--that you can manage application dependencies in a system-wide, one installation fits all fashion--to be true, but I've only ever seen it work in the most trivial situations.

Re: Avoiding The Vendor Perl Fad Diet — From: http://openid.aliz.es/sysop

2012-01-26T14:29:02Z

You've made it clear in past discussions you're not really focused on administration, which is fine, because you're a developer. But I'll say it anyway:

This was a good move by Red Hat. local::lib and perlbrew (et al.) are great for development, embedded deployment, and so on, but when it comes to doing real-world systems administration, you need to be able to manage perl, and it doesn't like to be managed. We tried putting site_perl on an NFS share from an Isilon system; that resulted in a massive network storm any time anything on the HPC grids fired off... which then slowed our engineer's workstations down to a crawl. We've tried a million things, and what we finally wound up doing was handcrafting packages for ExtUtils::MakeMaker and things like it, which basically dropped into site_perl (instead of vendor_perl, where packaged goods normally fall).

The thing is, ExtUtils::MakeMaker is really important for building modules. What it's not important for is running perl programs. Furthermore, that specific module (among others) is not necessarily tied to the version and patchlevel of the perl binary. Perl 5.8.8 works just fine with versions of MakeMaker from far off in the distant Jetsons-like future... but because RHEL5 has MakeMaker in the perl package, you have to jump through fantastically annoying hoops to upgrade it on a 500-node grid.

Now, I agree that when you run 'yum install perl' you should get the whole distribution... but the 'perl' package should be a metapackage which weakly depends on modules like MakeMaker. That way I can use standard tools to support building newer versions of MakeMaker when some CPAN module suddenly decides it needs a newer version of that module (which often happens when CPAN dependencies are carelessly managed).

Redhat's only real mistake here was calling the package 'perl' instead of 'perl-runtime' or whatever the bikeshedders decide is an appropriate name.

Your advice, as I mentioned at the beginning of this comment, is sound for a development platform. There is almost nothing more annoying than finding out during a complex analysis deployment that the developer's code doesn't work because he was too clever by half -- and started dicking with perl build options to the point where his code won't run on our existing perl deployment.

We have something like 2500 things installed from CPAN (no matter what the language faddists say, tons of computational science is done with perl). Having to replicate the frequently-massive dependency trees that analytical software can have -- to the extent of including entire other languages liek fortran -- every time for every program is simply ridiculous. A web application? Fine, push your perlbrew to EC2 and move on. But for large installations, you can't just maverick off into your own little development walled garden. You have to coordinate with your systems administrators, because they generally don't have the manpower to shove your entire development stack into the configuration management... and then do it again for the next fifty programs.

When you're trying to do performance-critical work across hundreds or thousands of nodes, your software needs to be packable. Distributions have tools to make software manageable, and ignoring them make life harder for everyone but you.

Re: Avoiding The Vendor Perl Fad Diet — From: i.galic [launchpad.net]

2012-01-26T12:40:39Z

@szabgab.com: On Debuntu Ruby is nearly unusable. Especially in regard to gems.
We develop heavily in PHP and run the latest, often a beta.

There's hardly any vendor who does not cripple a package. Some go the extra length to cripple all of them.

Re: Avoiding The Vendor Perl Fad Diet — From: randomness.org.uk

2012-01-26T09:38:25Z

This is one of things SUN got right in Solaris. the perl they needed for system stuff was elsewhere and not in the users path.
Admittedly there were issues with the perl for users as well such as using the sun compilers so it was always better to use your own perl anyway if you couldnt afford the sun compilers.

Re: Avoiding The Vendor Perl Fad Diet — From: https://me.yahoo.com/mjgardner#d9855

2012-01-26T02:23:12Z

szabgab: Vendors often provide -devel package containing the bits needed to build XS-based packages against system libraries. Sometimes it's not enough, though -- Subversion for example really wants you to build its swig-based bindings from the same sources as the client, which necessitated the Alien-SVN distribution on CPAN.

Re: Avoiding The Vendor Perl Fad Diet — From: chromatic

2012-01-25T23:02:45Z

As I wrote, this is why (vendors) need to provide packages of Perl Actual.

Don't get caught up in the fact that people in the know can compile their own Perls. The entire point is that the balkanized and bowdlerized installation media Perls are only suitable for the other programs on the installation media.

Re: Avoiding The Vendor Perl Fad Diet — From: grantmclean.myopenid.com

2012-01-25T22:27:44Z

I don't really have a problem with vendors carving up Perl into separate packages as long as *everything* goes into one of the parts and ideally there should be an easy way to install all of those packages.

I've been developing and deploying Perl code on Debian for years and have had no need for perlbrew. I'm not saying there's no place for it, merely that I have found the Debian Perl ecosystem to be 'good enough' that I haven't needed it. Installing CPAN modules via .debs certainly makes for easy deployments.

szagab: In my experience Ruby is a nightmare to deploy and most people use RVM (perlbrew for Ruby) and bundle all the versioned module dependencies into the app. In the PHP world it is common for vendor packages to lack features or fixes that would be available to someone building from source - however the typical response is to do without rather than build from source. I don't know much about Python but have heard murmurs that vendor tools written for Python 2.x are a barrier to deployment of 3.x.

Re: Avoiding The Vendor Perl Fad Diet — From: szabgab.com

2012-01-25T20:53:39Z

So what about Python, PHP and Ruby? Do developers in those languages also need to install from source or can they use the one that was supplied by the vendor?

What if you wanted to use mod_perl? Do you need to also compile Apache from source? What else do you need to compile from source?
Do you then need to keep an eye on new releases of all these libraries and applications to apply security patches?

Re: A Decades-Old Technique to Improve Programming Languages — From: Leon Timmermans

2012-01-24T22:32:08Z

Yes, exactly. I want this, preferably yesterday. Sadly, this is not going to be easy to implement, not in the last place because it's hard to do it incrementally.

Re: Imagine if caller() Returned Stack-Capturing Objects — From: Sue D. Nymme

2012-01-20T05:48:21Z

Imagine if you could goto the stack object, to effect a return from the subroutine at any point.

Re: Imagine if caller() Returned Stack-Capturing Objects — From: ilmari.org

2012-01-19T10:26:25Z

This seems to be more or less exactly what Devel::StackTrace provides.

Re: Testing Your Templates, and Why It Doesn't Always Work — From: https://me.yahoo.com/mithaldu#29f3a

2012-01-19T08:55:03Z

I was talking in more general terms. Factually i'd say that if you're pushing anything to the template render that is not a simple hash/array/scalar structure you're doing something wrong; similarly, if you're using anything beyond GET/IF/LOOP instructions in the template, then you have too much logic in there as well. Text::Xslate helps because it has more useful error messages and can tell you about undefined values without getting all crazy, and because it doesn't support some of the more outlandish parts of TT.

HTML::Zoom takes an entirely different approach: You hand it a normal piece of HTML and then instruct it via CSS selectors to fill in, or repeat or cut out certain parts of the template. All of this happens within the Perl code, so you end up with templates that are completely testable.

Re: Testing Your Templates, and Why It Doesn't Always Work — From: chromatic

2012-01-18T19:19:41Z

How would you rewrite this template to avoid the conditional? Am I misunderstanding--are you suggesting that the template language should not allow method calls on objects?

If so, I think that pushes logic too far out of templates.