Why non-core CPAN modules can't be used in large corporate environments.

[Moron]

This was prompted by a number of other threads and I wanted to get to the heart of this matter.

Let us consider the typical case of a production system undergoing enhancements currently, but which first incorporated several years ago, using say Perl v5.004 under either Linux or Solaris. In most cases, and certainly for mission-critical systems, all software goes through a lifecycle of development and three levels of testing (unit, integrated and acceptance), before getting through to production.

Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated involving a variety of people from different teams, adding up to an overall expense that is hardly likely to be met by any compensating business benefits the developers can find.

Occasionally some major event will occur, such as a new version of some major package the system uses, whereby the Perl upgrade can be bundled in. But given the cost, such a miracle is only likely to occur about once in five or ten years for the mainstream of corporate systems. It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1. Maybe one day in the distant future that module may be compatible with these production systems but maybe the minimum for the version in CPAN will be 5.10 or 6.3 by then.

Impact for monks: So, in the meantime, most developers in large corporate environments need non-module programming solutions and core module solutions but cannot use solutions which refer to a non-core CPAN module and for these purposes, core means "core in the late 1990's"!

[rinceWind]

PAR provides a good solution here. I have successfully used it to deploy Perl code into production, in an environment hostile to open source, and to Perl by implication.

Using PAR, what I am delivering is a PAR executable, the source being a Perl script. Such an 'executable' is taken through a full development and testing cycle before being put live.

Because PAR executables include perl itself, you eliminate the dependency on perl versions. You also eliminate the module interdependency nightmare that afflicts applications that use CPAN - this is moved back to 'development', where it belongs.

Also worth mentioning is the isolation benefit that this gives you, in that each application so deployed, indeed each version thereof, is independent of every other application deployed.

[Moron]

An interesting idea, although owing to the complexity and number of constraints I didn't even get round to mentioning in my OP report, it will take time to evaluate what PAR can do to help, but I'll certainly look into it, thanks for the suggestion.

[BrowserUk]

That argument makes no sense whatsoever.

At the point in time where a new application is developed & tested,i.e. pre-production; it is completely acceptable to use whatever CPAN modules that are available at that time, in the development of that application.

For existing applications, if you are adding new code to the codebase, regardless of whether that new code is developed totally in-house, or utilises one or more CPAN modules; you still have to go through the same, identical testing process.. The only time you avoid testing, is if you make no changes at all. And if you are making no changes, the subject of CPAN modules doesn't arise.

What you appear to be saying is that if you are developing a new application, and already have an existing one in production that uses some ancient version of Perl, and is so badly coded that you are scared to upgrade it, that your new application has to use that same ancient version of Perl. That's stupid.

It is entirely possible and practical to have multiple versions of Perl installed for different applications. Just don't add them to the path. Put the appropriate version of Perl into the application subtree and put a simple shell command into the path for each application that sets the path up for that application and invokes it.

Call it "loose coupling", "breaking dependency chains", or "application independence management". Avoiding locking your entire development effort into choices made and facilities available 5 or 10 years ago is the first thing on the curriculum of 'Business Application Management 101'.

It's the same lesson that was being learnt in corporate development shops in the mid '80s about getting locked into a single language or version of a compiler. Eventually, and sooner rather than later, the supplier of the compiler will drop support for the version you have selected as your 'one and only'. Or worse, the supplier will go bankrupt or be bought out and the compiler will simply become a zombie.

If each new development is made with the latest, stable, tested and certified version of whatever language/compiler makes sense for the project, when support for old versions is dropped, you only need to upgrade those projects that made use of that version--not your entire application suite.

You also get the side benefits of:

• Each project benefits from the latest technology.
• Each project can choose the language/compiler most appropriate to it's requirements.
• Each project can benefit from the availability of new third-party libraries that become available between projects.
• When the crunch comes 10 years from now and you are forced to upgrade projects that used tools that are no longer available or supported:
  1. Only one or two projects are affected each time.
  2. You don't find yourselves scrabbling around, paying premium prices for the very limited pool of programmers that have any residual expertise in that obsolete technology--at exactly the same time as every other company locked into it will be doing the same thing!.

I realise that companies are still making this mistake--in some cases for the third or fourth time in the last 30 years--, but if you have any influence whatsoever when the a new generation of bean-counters re-invent the "All new development will use version P.Q.R of language/compiler XYZ from now till doomsday (or the sh*t hits the fan)" directive; gently point out that 'doomsday' and 'the sh*t hitting the fan' are the same thing, and like all non-specific statutes of limitation, it always arrives sooner rather than later, and much sooner than their spreadsheet projections predict.

Actually, sod "gently", do it forcefully!

[mirod]

Couldn't "developers in large corporate environments" try to backport the modules to the version of Perl they are running?

Instead of re-writing a module why not take a look at the code and see if you can patch it to work for you. You can even have the makefile pre-process the module if it finds that the running version of perl does not support some constructs. For example 3 argument open, use of our or even the qr// construct. Done properly this should not intrude on the code for quite a few modules. Oh, and don't forget to send those test reports for old versions of perl ;--)

It seems like a win-win situation to me: you get a proper module in less time than it would have taken you to write it, plus support and new versions, and the author gets users, patches and a module that works on more systems.

[Moron]

In theory yes, but what is logical for a developer is not always achievable in a multi-functional environment where many teams other than development have a say about what can go into production. In addition, Perl has to compete with other languages at that level and anything that looks like awkward procedure to non-developers can be hard to sell in that context - one might instead get asked to propose a non-Perl alternative solution.

[thor]

Every non-trivial technical package has this problem. Also, if the "non-developers" are making all the decisions without developer input, I guess I'd have to ask "why?". Who better to assess the situation than the guy that has to deal with it? Also, how much money are you spending re-inventing wheels?

[DrHyde]

Yes, they can backport. I have on several occasions. See also my post here Use of 'our' considered harmful.

[tirwhan]

Seems to me like there's a logical fallacy in your argument. Just because some/many modules on CPAN don't work for the version of Perl used on your production systems does not mean none of them do. Naturally, when looking for a solution to a problem you should take into consideration whether a given CPAN solution works for your production environment, that seems to me as obvious as not trying to use Win32:: modules on a *NIX system. But you should not conclude that you cannot use any CPAN modules because some of them don't fit your needs.

Also, some developers make an effort to keep their modules as backwards-compatible as possible, and if you tell a developer that you would like to use his module but can't because your version of Perl is older than his module's minimum requirements he may try to adapt the module to suit your needs (especially if your request is accompanied by a suitable patch, as suggested by mirod :-).

And I'd posit that a good system should be written with upgradeability of the underlying platform kept in mind, and a cardinal rule for that is "don't use undocumented or deprecated features". I am perfectly aware that this is often not possible without huge effort (particularly since the time-machine which lets you preview future features of Perl seems broken again), but it should be one goal when writing such a system. Sticking to old and deprecated platforms can create massive problems at a moment's notice (like when a serious security flaw is suddenly found and no fix is backported), and while it's sometimes unavoidable it should not be a goal IMO, or considered "the way things are done".

[Anonymous Monk]

Seems to me like there's a logical fallacy in your argument. Just because some/many modules on CPAN don't work for the version of Perl used on your production systems does not mean none of them do.

Indeed, this is called the fallacy of composition, commonly summed up in the phrase, "don't throw the baby out with the bath water." And it's exactly what Moron has done with his post. It's heartening to see all the monks who picked up on this and are trouncing it superlatively.

[adrianh]

So, in the meantime, most developers in large corporate environments need non-module programming solutions and core module solutions but cannot use solutions which refer to a non-core CPAN module and for these purposes, core means "core in the late 1990's"!

Having been doing commercial perl work for nearly ten years now I can only think of two clients who did not use CPAN modules all over their code. They were, in my opinion, idiots and wasted time and resources reimplementing stuff that was there to download. And in one of those instances it was because they were "scared" of open source rather than due to any maintainability issues.

Three things make this a non-issue:

• Most of CPAN works quite happily on older perl's. I've recently been doing a bunch of work on a codebase that uses 5.6.0 for reasons to dull to go into. 99% of everything still "just works"
• In the cases where it doesn't work the source code is available. Most of the time it's easier to backport than it is to reimplement
  .
• Any professional organisation has roll out processes, test suites, etc. That make migrating code to newer versions a business issue, rather than a technical issue.

So pretty much a non-issue in my experience.

[perrin]

Backporting a module is likely to be faster than writing from scratch. If they can put their own code through to production, they can put code that they backported through as well. Many CPAN authors would appreciate receiving backport patches, especially well-tested ones.

[Moron]

True, although once you get into the guts of that, it seems more appropriate to use technique from the module to fit your system - the functionality the module delivers in such situations is usually small compared with what has already been developed for the target system, so it is often easier to move Muhammed to the mountain than vice versa.

[perrin]

Sure, just glance at the DBI, HTML::Parser, Template Toolkit, and LWP source code, and then write your own. Have fun.

[dragonchild]

It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1. Maybe one day in the distant future that module may be compatible with these production systems but maybe the minimum for the version in CPAN will be 5.10 or 6.3 by then.

Setting aside the fact that most modules on CPAN take great pains to be backwards-compatible with at least 5.6.0 (or earlier!), you can always see every single upload to CPAN through use of the BackPAN. So, you can always get at the version you want to use today, but can't until next year.

As for version compatibility on CPAN ... I'm of two minds. In Excel::Template, I actually have an eval-block to determine if I can use 3-arg open or if I'm at a version that requires 2-arg open. In PDF::Template and PDF::Writer, I require 5.6.0 at a minimum. I don't depend on 5.6 features, but I feel that it helps stabilize my testing burden because I don't need to keep a bunch of different versions of Perl around. Now, if there was an easy way to have Test::More or Module::Build run a test suite against various versions of Perl and report errors by Perl version, I would change my tune. Or if there was documentation of how to tune your code to be more in tune with the version of Perl it's running under, then I'd have no problem. Older versions of PDF::Template actually have provisions for whether or not to use Unicode::String based on Perl version, but it uses PM_FILTER which is marked "DO NOT USE" in ExtUtils::MakeMaker and I haven't seen the way around it in Module::Build.

[radiantmatrix]

I find your reasoning a little suspect:

Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated...

In fact, that isn't typically true. All that's required to move from one version of Perl to another would be regression testing, which is typically automated, followed by a brief UAT period. If there are problems, then you can get into software development cycles, but such problems don't often occur (and are typically failry minor when they do).

It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1.

There are not all that many modules which require 5.8.x. Most of the time, when I see people asking about solutions that use core modules only, the CPAN modules that would solve their problem work just fine with quite old versions of Perl. A more reasonable request would be "I have perl 5.6.1 and that can't be helped: so I can't use any modules that depend on newer versions." Unfortunately, that's not what we see, most of the time.

There are only two common reasons for a corporate requirement of "no CPAN modules": code vetting and licensing.

In many organizations, any production code must be vetted by Quality Assurance (QA) and Security Review (SR) teams. Sometimes both functions are performed by QA. In any case, the core Perl distribution tends to have been vetted by these teams as safe for production use. All code written in-house will follow corporate coding standards and is therefore a bit easier for QA/SR to clear for production. CPAN modules (a)are a bit harder to review and (b)might have to be handled outside the project, slowing production. It would be easy enough for a corporation to establish a better review process for CPAN modules, but often they apply the same rules that were designed for external modules in other languages (which often do not have source code). The coder on the floor doesn't usually have enough pull to get the policy adjusted.

As for licensing, many CPAN modules are GPL or a similar "viral" license, and that makes legal types nervous. We all know that using modified GPL software internally creates no burden, but corporations tend to be risk-averse and would simply rather avoid the potential for licensing concerns. Thus, policies grow that forbid external modules without a long and painful code- and license-review process.

[Tanktalus]

Side note...

I've faced this problem. I tackled it. (With actually some good help from my first line manager - possibly higher, I'm not sure.) We now have multiple versions of perl in production. Older code uses older perl, new code uses newer perl. In fact, my code runs on perl 5.8.7 on Unix/Linux and 5.8.6 on Windows (due to a problem we had on unix/linux which wasn't relevant to windows - no desire to upgrade windows again), while the code from other teams runs on 5.8.1 or 5.6 or even 5.005.

The 5.8.7 install has the 5.8.6 lib directories in its hardcoded @INC. The lib directories are shared across all platforms (including Windows, I think). And I have a way of hacking in new CPAN modules at runtime (thus far, they're all pure perl which makes it trivial, not sure if I'm brave enough to try XS or Inline::* code...).

This is a fairly large software company. (Our building has about 2500 people - software developers and support, such as IT, management, customer service, HR for software development, but not sales, corporate management, lawyers, etc. And we're not the only developers in the company.) It's just a matter of aligning the priorities and making sure everyone gets what they want. Management wants to ensure nothing is broken. Thus, keep the old versions of perl. Management also wants fast development. Thus, new versions of perl need to coexist in a way that allows us to get new CPAN modules.

I actually got this ball rolling when we started investigating XML-based technologies. There was no way I was going to do that by hand - I got my manager behind the idea that we needed XML::Twig. And we pushed from there - "No way to hit our dates without this." As in, yes, we can do it, but not by the end date you want it to be done by. That brought extreme amounts of pressure to resolve the situation.

Of course, if your management says, "Ok, we'll move out the dates," then that's what you do. You rewrite stuff that would work fine if they were willing to have a parallel perl that was up to date. But they're willing, instead, to pay you to reinvent some wheels. That is their perogative. ;-)

[Perl Mouse]

The number of things new in 5.8.x as opposed to 5.6.x are extremely limited - and if they were it's mostly things that weren't possible in 5.6.x or are vastly improved (threads, Unicode).

The change between 5.005_xx and 5.6.x is bigger, our, lexical warnings, and autovivifying of filehandles come to mind.

Hence, a CPAN module either uses something specific to 5.8.x (and hence, you wouldn't even attempt to use it in 5.6.x), or it's just going to work in 5.6.x. And even if you're dragging 5 years behind in perl releases, you're on 5.6.x. 5.6.0 was released in March 2000.

BTW, you are talking about most developers in large corporate environments. Where does that statistic come from? How many large corporate environments do you have experience with?

[dragonchild]

I don't mind compromising my privacy (because I have done so already on this site). In my experience in at least six major corporate environments (including a bank and a credit card), things are often how Moron describes them. However, the larger and more stratified the environment, the more often you see the rules being broken. For example, in $HUGE_BANK, the requirements for Perl version varied wildly from group to group and even app to app. I remember having to comment out "use warnings;" in a sysadmin script because the version on the one server they were running on was 5.005_03 while the sysadmin (who wasn't there) was used to running his private 5.8.4 install.

In $CREDIT_CARD, we were up-to-date on Perl version, but a version behind on PDFlib and 2 versions behind on a middleware. The key to these decisions was $$. Perl was free, so the upgrade could be done when the developers had time to evaluate. Everything else cost money, so the upgrade could only be done when the funds were approved AND the developers had time to evaluate. Which do you think happened quicker?

Things like this often depend very heavily on the first and second layers of management right above the senior developer vs. some random corporate policy. Anything above the manager's manager and they don't want to know the details. If your manager's manager has lots of clout, you get stuff done. If they don't, you likely end up finding a new job cause you hate it where you're at. *shrugs* At least, that's my take on it.

[TomDLux]

At the mega-corp where I work, the administrators have mechanisms to provide different versions of Perl ( & Vi & Emacs & Informix & Sybase & .... ). Last year they stopped supporting Per 5.005. Modules are available in multiple versions, and a special versioning feature is used prior to the 'use' statements to specify which version of a module to use.

That makes it the responsability of the programmer to update script X from Perl5.6 to Perl5.8, or to move from one version of DBI to a more recent one. There's no reason for my monitoring script requirements to affect the performance of your data loading script.

Just this week I am migrating a set of scripts from 5.6 to 5.8. I didn't want the bother, until now, but a bug has appeared which makes the migration necessary.

[ysth]

In several places in this thread, you use the term "multi-functional". Can you explain what it means to you?

[Juerd]

You seem to ignore the simple established fact that

non-core CPAN modules are used in large corporate environments.

Very rarely I respond to only the title of a node. But in this case, it's so dumb that I could not resist.