

Perl and Perl Module Administration in the Modern Era - draegtun
https://speakerdeck.com/djerius/perl-and-perl-module-administration-in-the-modern-era

======
richardwhiuk
curl -skL <http://install.perlbrew.pl> | bash

Please stop doing this. At the very least, do it over HTTPS.

~~~
Mozai
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.

------
zdw
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.

~~~
kbenson
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. :)

~~~
mechanical_fish
I don't work with Perl anymore, but the same problem has played out in the
Ruby space, with the same conclusions.

~~~
kbenson
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.

