Front page | perl.perl5.porters |
Postings from March 2023
On Tue, Mar 7, 2023 at 8:14â¯PM Joel Roth <joelz@pobox.com> wrote: > > With that bit of hand-waving, I have a local, per-client Perl, configured > > how the client needs it, and automatically pointing to local (per > > directory) CPAN installations. This allows me to create an isolated setup > > that doesn't risk interfering with another Perl installation or its > modules. > > plenv might need enhanced if you want to specify the > local::lib for a particular directory. We previously got > this behavior by letting perl load libraries from the > current directory. > > 1. https://github.com/miyagawa/plenv-contrib > Thanks for that, Joel. So I think the overall idea is better explained now. There's plenty of CPAN evidence that this is both feasible and desirable. As the default situations stands now, we have this from the node.js blog <https://nodejs.org/fr/blog/uncategorized/development-environment/>: CPAN and RubyGems have blurred the lines between development tools and > system package managers. With npm we wish to draw a clear line: it is not a > system package manager. It is not for installing firefox or ffmpeg or > OpenSSL; it is for rapidly downloading, building, and setting up Node > packages. npm is a development tool. When a program written in Node becomes > sufficiently mature it should be distributed as a tarball, .deb, .rpm, or > other package system. It should not be distributed to end users with npm. I believe the above paragraph is correct and sums up what I would love to see addressed. Getting a similar *development* tool in the Perl code. So getting back to the original question that I fumbled so badly :), is this something P5P would be willing to see in the Perl core? If so, while I wasn't intending this to be a pre-PPC, should one follow, or should a PPC be written? Best, OvidThread Previous | Thread Next