Managing Non-Standard Modules
Before I get into solving some of the web-related programming problems that I mentioned in the last post, I wanted to talk about the CPAN. The CPAN is an incredible, time-saving source of modules to add to your Perl installation. At the CPAN, you'll find an extremely wide range of plugin modules covering many functionalities (too many to list here). This should be your first source of any code that is not a part of the standard Perl distribution. If you cant find it here, then you'll probably need to write it. (Code that's put here is tested by various people that are part of CPAN. Perl code that you find on other websites is another source, but possibly less reliable. What's more, they are usually not in plug-and-play modules like they are at CPAN.)
Over the past 10 years of using Perl in small web scripts (CGI) and large programs (5000 lines or more), I've located software at the CPAN countless times. Because this repository contains code contributed by other Perl developers, there are occasionally modules with essentially duplicate functionality. Over time, duplication is somewhat weeded out. Some of the more popular modules over the years have ended up becoming part of the standard Perl distribution (the how and why is beyond the scope of this blog entry).
Unfortunately, the drawback of the CPAN is that the modules there ARE non-standard. Many companies that use Perl code have a policy of not allowing the installation of non-standard Perl code, especially if they have many thousands of computers to upgrade. Case in point, I contracted for IBM Canada a few years back. Part of my job was to write code to parse some "help" files that had markup that resembled HTML or XML, but weren't really. I tracked down a couple of suitable markup-parsing modules at CPAN, tested them, then checked with the support team. Sorry, they said, they couldn't allow these modules because of the headache of installing them on thousands of personal computers at many locations in Canada and the US and even in Europe. The code I was writing would get batch installed in the appropriate location, but non-standard Perl modules had to be installed in numerous directories, causing unnecessary work for the install team, as they would separately have to make sure each module didn't break anything else in the humungous software system. Understandable.
At this point, I'd spent a fair bit of time on the problem, and I was a contractor. I couldn't waste too much more time without upsetting the client. I had two choices: (1) Write my own parser or (2) port the modules to be part of a set of "local" modules. Ultimately, I ended up doing both. Some of the modules I had to rewrite because the customization I need was faster to do from scratch. But other modules simply needed a bit of modification.
I first moved each module from the directory it would have resided in, in the Perl distribution, to the same directory that my code was in. I.e., the modules were made local relative to my program. Then I edited each module by changing all path references to the original module location so that the reference was "local". Many times, that's all that was needed. If testing proved otherwise, I sometimes also found that I had to recursively do the same to other modules called by a given localized module. If after similar tweaking, I couldn't get a module to work, I scrapped it and wrote my own code, usually as a module.
(c) Copyright 2005-present, Raj Kumar Dash, http://perl-tips.blogspot.com
Over the past 10 years of using Perl in small web scripts (CGI) and large programs (5000 lines or more), I've located software at the CPAN countless times. Because this repository contains code contributed by other Perl developers, there are occasionally modules with essentially duplicate functionality. Over time, duplication is somewhat weeded out. Some of the more popular modules over the years have ended up becoming part of the standard Perl distribution (the how and why is beyond the scope of this blog entry).
Unfortunately, the drawback of the CPAN is that the modules there ARE non-standard. Many companies that use Perl code have a policy of not allowing the installation of non-standard Perl code, especially if they have many thousands of computers to upgrade. Case in point, I contracted for IBM Canada a few years back. Part of my job was to write code to parse some "help" files that had markup that resembled HTML or XML, but weren't really. I tracked down a couple of suitable markup-parsing modules at CPAN, tested them, then checked with the support team. Sorry, they said, they couldn't allow these modules because of the headache of installing them on thousands of personal computers at many locations in Canada and the US and even in Europe. The code I was writing would get batch installed in the appropriate location, but non-standard Perl modules had to be installed in numerous directories, causing unnecessary work for the install team, as they would separately have to make sure each module didn't break anything else in the humungous software system. Understandable.
At this point, I'd spent a fair bit of time on the problem, and I was a contractor. I couldn't waste too much more time without upsetting the client. I had two choices: (1) Write my own parser or (2) port the modules to be part of a set of "local" modules. Ultimately, I ended up doing both. Some of the modules I had to rewrite because the customization I need was faster to do from scratch. But other modules simply needed a bit of modification.
I first moved each module from the directory it would have resided in, in the Perl distribution, to the same directory that my code was in. I.e., the modules were made local relative to my program. Then I edited each module by changing all path references to the original module location so that the reference was "local". Many times, that's all that was needed. If testing proved otherwise, I sometimes also found that I had to recursively do the same to other modules called by a given localized module. If after similar tweaking, I couldn't get a module to work, I scrapped it and wrote my own code, usually as a module.
(c) Copyright 2005-present, Raj Kumar Dash, http://perl-tips.blogspot.com
| Permalink | E-mail this post 
