Perl and Perl Module Administration in the Modern Era

That's going to go terribly awry with today's mention of ISPs that inject their own code into HTTP responses. I mean, aside from the "inspecting the barrel of a loaded gun" factor.

You're missing (at least some of) the point. It's useful to have different versions of the interpreter installed (at the same time) and easily accessible, and it's also useful to be able to switch between them easily. With the addition of easily switchable library paths (per version, as they show) as well, this makes it easily to test entirely different stacks easily.

Additionally, there's the problem of perl (python as well for the last decade) being used as glue for many OS-level tools. Have you ever tried replacing the packaged Perl on a n RHEL box? It's not fun. Also, since it's relied on by so much within the distro, the chances they are going to go through the trouble of updating the version and risk problems is very small. On enterprise distros, you are essentially stuck with an out of date Perl before the distro ships, and stuck with it for the long support lifetime.

This is frustrating to the perl community, as anything that requires "new" features faces limited adoption as a significant portion of the community can't run those versions.

That's not to say that packaging perl isn't the way to go. I believe in many cases it is. I also think it depends on your targets. Three webservers does not make the same argument as a farm of boxes. Even so, the ability to easily test and iterate in your dev environments, before committing resources to building packages and pushing them to QA, is a good thing.

Edit: Changed redundant "additionally" to "also" so it wouldn't bother me anymore. :)

What you've described is the internal policy at the company I work for, and its a total nightmare. You don't get new versions of software until you upgrade your entire OS, a non-zero amount of developer time is spent re-packaging things that have already been packaged (and their dependencies!) and if you want to run multiple versions concurrently, you have to resort to horrible hackery as aptitude doesn't support that.

Sorry, no thanks.

Using perlbrew, I can install a version of Perl without messing up the system installation, as would the default package manager. I have to migrate data from a legacy Catalyst app which pulls in a lot of modules with specific versions, which should not reside in the OS package management system (nor should the OS try to update them).

Thanks for the FPM-link, that looks interesting for packaging my own software :)

I see where you're coming from, but I think there's a place for these, even though I wish there was a unified solution.

I do like the "isolated" package management these systems offer, and would like to see a good way for user-level packaging to be managed in a more universal way. It's extremely useful to be able to deploy multiple isolated environments, with conflicting dependencies, on the same server and not affect the system libraries in any way.

Say I need libfoo1.1 that conflicts with the system version for project A, and when related project B rolls around, it needs libfoo2.0 in the same system. Do I build a series of _project_A.deb and _project_B.deb packages, with separate install prefixes, and rebuild their associated dependencies in turn?

Large deployments are often very complex systems, and being able to decouple individual environments is a huge improvement.

You'd certainly need something that can install a new Perl runtime and install the CPAN dependencies to a separate directory from the ones used by the system. Otherwise you're tying your platform and your applications unnecessarily together.

Me too man but I gave up that dream a decade ago.

The hot-new-scripting-language community and top-two-or-three-linux-distro communities just never seem to get along well enough to eliminate this needless layer of duplication and complexity. IMHO its a lot more about fiefdoms and autonomy than technical considerations.

I partly agree. I've worked at various times in my career as a developer and as a sysadmin. When I've worked with Perl is has usually been in my sysadmin role and the advantage that Perl has always had in that role is that it is part of the system. I can always rely on at least Perl 5.6 as being available as part of the system and I can write Perl scripts targeting it in almost the same way I can write scripts targeting the Bourne or Bash shells. Not having to deploy a new interpreter or package management system on my targets makes things much, much easier.

At the same time, I've worked as an application developer as well, and in those circumstances I generally want the latest versions libraries and interpreters. Since I'll be writing all the code expected to run with them, stability is less important. I can work around bugs and incompatibilities myself. Generally though, I need to make sure that my application interpreter and libraries don't interfere with system equivalents because that is a nightmare. So a secondary package system makes sense in this case.

What I would like ideally, is a OS package manager which is capable of handling multiple versions of a programming language gracefully and will let me install a development version alongside a system version, as opposed to hacks like rvm.

I find it ironic that the directions for installing FPM are

  gem install fpm

I agree about using system packages for deploying a stable production system. But tools like perlbrew, rvm and virtualenv have less friction for development when you want to quickly test or switch between different versions of the interpreter or libraries.