develooper Front page | perl.perl5.porters | Postings from March 2023

Managing Perl installations

Thread Next
March 7, 2023 09:01
Managing Perl installations
Message ID:
Hi all,

I'm sure this has been discussed before, but I find it hard to search
effectively with

The problem: a new client is using system Perl for a large product that's
been running for decades. Many of *their* clients have the code installed
locally, so it's non-trivial to fix.

Clients who use this can write plugins for the code, but due to their
understandable desire to not risk breaking system Perl, they will often
cut-n-paste CPAN modules into their plugins. Many of their plugins are
included in the core code base for the product. Also, some non-core modules
get installed into system Perl!

So we have an issue where we sometimes have multiple versions of a module
available and it's the luck 'o the draw which version gets loaded first. We
have plans to fix this, but some other work we're doing now takes priority,
so fixing it takes a back seat.

Other languages bundle tools which allow you to build and install
"per-project." Perl has Carton, Pinto, perlbrew, plenv and a whole host of
tools which can help with this, but setting those up has a bootstrapping
issue. Let's say we want to install perlbrew so that we don't mess with our
system Perl. That means we install it with system Perl and the META.json
<> show
a number of dependencies which might alter our system Perl. I think
installing from avoids this (it's fatpacked), but ask
a sysadmin if they're comfortable running \curl -L | bash and pipe some random website's code to

If I'm not already intimately familiar with Perl, I might not realize the
problem, or know how to find the answer to this problem.

I think the Perl core should consider a solution for this.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About