Modern Perl

To /inc or not to /inc?

I currently use the awesome Module::Install as an integral part of my development and deployment tool-chain.  What this does for me is make it easy to not worry about my project dependencies, nor my target deployment box.  It makes it easy for a group of developers working on the same project to keep well in sync with each other regarding dependencies.  Although it does have its detractors I think it has far and away become the favored installer of modern Perl developers.

One thing that is troubling me is whether or not to check in to my repository that "inc" directory that gets created (along with the pile of required Module::Install files as well as any extra plugins you my have installed) when you run "perl Makefile.PL" on a Module::Install enabled Makefile.PL script.  In the past I have not, but lately I've seen quite a few projects on github that have.  I can see the upside, since checking in those files would make it easier for another person to checkout your code and just get to work, if that 'inc' is missing you may have to install Module::Install and whatever other plugins you favor, which has been a bit of a gotcha for some of my newbie developers.

On the other hand if I do check that stuff in I might end up with extreme version lag behind Module::Install releases and that increases my risk of regressions when I do upgrade.

So... What are you all doing?  Do you checkin inc or not?  Why?

More inflamatory remarks

Okay,

So a lot of people seemed to think my last post was a bit inflammatory, although it did get some sort of result out of Google so mission accomplished.  I also want to thank some of the other Perl developers like Time Bunce and Rohan Almeida who stepped into that discussion and got down to business.   All very positive!  I'm actually writing a followup this weekend.   Yeah that should have been last week, but got a bit delayed since I had a suddenly illness in the family last week, and family first right?

Regarding some of the stuff over on the Reddit thread, I do actually appreciate most of those remarks, even the silly ones since they will provide an awesome chance to dispel some Perl myths.  Also appreciate those who represented over on the Reddit thread.  I personally stayed out since generally I prefer not to interfere with discussions on something I wrote unless I'm asked.  I'll comment in detail later.

Since 'fresh meat' seems popular (only my "Why do people Hate Perl?" article was more popular in terms of unique visitors) here's some more:  'Consultants' getting $722M from city for doomed CityTime computer project.

The NYC web site on this is over here

So, I'm always interested in FAILED (capitalization warranted here I think) IT projects, since I think IT has a lot to learn (and the business users ordering the projects have a lot to learn as well).  One thing that strikes me is no matter how hard I dig I can't seem to find out what computer languages are involved in this fiasco.  Even the SAIC homepage doesn't mentioned any of the hard technologies they use to deliver projects.  Why not? 

For some reason I think there's something profound here, something which would probably help understand not only why this project is a failure but also explain why the US seems to be a decline (or at least many people perceive a decline) when it comes to producing the best and brightest in technology.  However I have trouble expressing it.  Any thoughts about this?

I'd also love to find out more stats on the costs and failure rates of IT projects broken down by language.  I think it might be hard to define failure sometimes, since people will often change the definition of success midway in order to CYA, but I guess we could say "under-delivered on promise" instead of failure.

My anecdotal experience is that Java projects are high on the failure rate, while folks building on many Microsoft Technologies are high on the 'under-delivered' rate (MS developers seem more willing to shift the goal in the face of reality, at least in my experience, the Java people tend to be stubborn.)  But that's anecdotal.  Where can I find more hard facts on this?

Oh, and to justify putting this under 'Perl', I have to ask, does anyone know of a single Perl project that failed after ten years and spent nearly $800 Million US Dollars?

Google: Do No Evil (to Perl?)

Google is making a major update to their Adwords API, which requires significant changes to any client language bindings.  These are SOAP based bindings.  Although there is a a client on CPAN, this module only supports API services up to version 13, which appears to be scheduled for decommissioning on April 22nd.  There is a Google developed replacement, which is not on CPAN, but on Google Code.   Unfortunately this module, besides being hard to install (doesn't use the standard CPAN toolchain), doesn't support the this new API.  In other words, on April 22nd SIGNIFICANT FUNCTIONALITY WILL PERMANENTLY BREAK FOR EVERY PERL APPLICATION USING GOOGLE ADWORDS API.

Google's suggestion is not particularly helpful.

In the past year I believe the Perl community has made good progress in addressing the gap between how valuable and widely used our language is and how it is perceived by people outside our community.  Unfortunately there is clearly still work to be done, given Google's lack of commitment.  It is really surprising to have someone at Google recommend migrating away from Perl as a solution to their API change.  I guess it points out how much work still needs to be done, but I have to express disappointment that such a kick in the gut is coming from Google, which has in the past been very supportive.

I realize that Google is in business to make money, not contribute free code to CPAN.  I should also acknowledge that we, the Perl community, bear some responsibility for the current state of affairs.  However as a company that built itself on top of open source technologies and continues to promote itself as a more open alternative to its competitors  I cannot see why it is so hard to build SOAP bindings for Perl.  Additionally I don't understand why Google seems so adverse to working with the standard Perl toolchain for delivering open source components (ie using CPAN.)

So...  Without screaming about how we should boycott Google, start using Bing and close all our gmail accounts, how can we as a community address this problem?  What would Google like to see happen in the Perl community in order to address this gap?  Who out there can help us communicate with Google and work together so that on 22 April 2010 those of us using a dynamic language with the happiest programmers,  strong job demand and serious commitment to open source won't be left in the dark on 22 April 2010? 

For me a reasonable solution would be a statement from Google expressing parity commitment to Perl equal to other widely used languages.  Additionally I would like to see a retraction of the sentiment expressed in the linked message board.  That would be a good start toward rebuilding this damaged relationship.

  

Bootstrapping local::lib, part 2

The cpanminus people (http://github.com/miyagawa/cpanminus) have this cool idea where you can just use the script hosted from github without even having to download it.  So you can do:

     curl -L cpanmin.us | perl - --help

and just use it.  This made me wonder if I could not do something similar with the script I recently blogged about.

      curl -L bit.ly/byYuxs | perl - -a $LOCALLIB_DIR

which is a little script (http://github.com/jjn1056/bootstrap-locallib.pl) that will bootstrap local::lib for you and install cpanminus so you can play with it.  Use like:

      curl -L bit.ly/byYuxs | perl - -a mylocallib

and it will run off and setup a properly bootstrapped local::lib in $HOME/mylocallib

I don't have a sweet hostname for this, but I figured with the pace of cpanminus development it will be obsolete shortly :)

Be aware that I install the CPAN version of cpanm, not github master, so is possible some features may lag from the most recent advertisements.  However for the three things I use CPAN it works for me 100% :)

You can 'activate it' like:

     $HOME/mylocallib/bin/localenv bash

which spawns off a subshell with local::lib enabled on your existing perl.  You can verify by:

     perl -V

and you will see that 'mylocallib' is added to @INC.  It will also add $HOME/mylocallib/bin to your $PATH.  When you are done just 'exit' the shell.  This way you can have as many local::lib's set up in your home directory as you have projects.

Since it installs cpanminus for you (into the local::lib) you can install a dependency quite easily:

     cpanm Some::Module::Needed

I find this is awesome for installing project dependencies.  You simple create your Makefile.PL and then do:

     cpanm --installdeps .

and all the listed required dependencies from your Makefile.PL will get installed into your local::lib

I imagine at some point all the features of my little script will be subsumed by larger projects, such as cpanminus or Module::Install::Bundle::LocalLib ,but right now I still find it useful.  Using it as above means you can try it without needed to download and setup anything.  If you give it a roll and have trouble please let me know.