Perl and Perl Module Administration in the Modern Era(speakerdeck.com)
speakerdeck.com
Perl and Perl Module Administration in the Modern Era
https://speakerdeck.com/djerius/perl-and-perl-module-administration-in-the-modern-era
3 comments
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.
This is stupid. The entire reason that people have issues with multiple versions of software is that they had to "roll their own" and don't bother to update it, thus they hit incompatibilities and need some sort of "bundling" utility like this.
If you're running any form of Unix, it's very likely that you already have a package management system. It's also likely that system has more features, and is better designed from a management and consistency perspective than any one of CPAN and it's descendants (gem, cabal, etc.).
A much better solution - either make your own packages, or use a tool like FPM (https://github.com/jordansissel/fpm) to make native packages, then deploy the result as you would any other package.
I hope for an era when running CPAN or gem interacts with the package manager, building a real OS-level package and installing/deploying it, rather than the current "you need to run this script incantation on every production machine, oh, and you need the whole toolchain too" idiocy.
If you're running any form of Unix, it's very likely that you already have a package management system. It's also likely that system has more features, and is better designed from a management and consistency perspective than any one of CPAN and it's descendants (gem, cabal, etc.).
A much better solution - either make your own packages, or use a tool like FPM (https://github.com/jordansissel/fpm) to make native packages, then deploy the result as you would any other package.
I hope for an era when running CPAN or gem interacts with the package manager, building a real OS-level package and installing/deploying it, rather than the current "you need to run this script incantation on every production machine, oh, and you need the whole toolchain too" idiocy.
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. :)
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. :)
I don't work with Perl anymore, but the same problem has played out in the Ruby space, with the same conclusions.
I think this is the natural state of things for any successful language.
Useful languages will be used.
Used languages will evolve.
Evolution may introduce problems with code written to an older version.
People that rely on older code will have some resistance to newer versions.
A natural friction will arise between those who wish stability in order to maintain, and those who which change in order to evolve.
IMHO if nobody cares about breaking older stuff, that just means that nothing useful has been written yet.
Useful languages will be used.
Used languages will evolve.
Evolution may introduce problems with code written to an older version.
People that rely on older code will have some resistance to newer versions.
A natural friction will arise between those who wish stability in order to maintain, and those who which change in order to evolve.
IMHO if nobody cares about breaking older stuff, that just means that nothing useful has been written yet.
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.
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 :)
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.
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.
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.
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 fpmI 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.
[deleted]
Please stop doing this. At the very least, do it over HTTPS.