Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations
Thread Previous
|
Thread Next
From:
Ovid
Date:
March 7, 2023 11:44
Subject:
Re: Managing Perl installations
Message ID:
CA+M4CHtyB2duYGzqiQoqbVDCCSC=P=f4UWTyE8t2XAfe7y1qhQ@mail.gmail.com
On Tue, Mar 7, 2023 at 11:17â¯AM demerphq <demerphq@gmail.com> wrote:
> On Tue, 7 Mar 2023 at 10:57, Ovid <curtis.poe@gmail.com> wrote:
> >
> > Caveat: I could just be a moron :)
>
> I certainly wasn't trying to imply that. I just wanted to be sure we
> were on the same page about what your "ask" is.
>
No worries. I was just kidding :) And with you "not trying to smart-ass"
comment later, I didn't take it that way, either. I know this is just
trying to suss out the issue.
> Ageed. I love perlbrew. But others seem to prefer alternatives.
Side note: I'm now being told offline that Carmel
<https://metacpan.org/pod/Carmel> is the way to go.
> It probably wouldnt be very hard to make it so that perl checks for a
> dotfile or something when it starts up to determine which perl it
> should use. Whether that would be *sane* is another, likely big,
> debate. :-) Consider that we avoid putting . (that is the current
> working directory) in lib these days, having a file in the CWD which
> determine which perl AND which lib dir you use seems like an even
> bigger security risk than just "dot in lib".
Agreed. I don't know what the solution is, but a dotfile probably isn't it.
>
> > What I would love, out of the box is something like this:
> >
> > perl -MInstall::Local -E 'install' options for configure
> >
> > 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.
>
> Well, using a module for this is a boot-strapping problem isn't it?
>
Hence the "hand-waving" comment. That would need to be a core module, or do
something like:
perl-local install v5.38.0
perl-local start # manual switch instead of a dotfile
perl-local start $name # use a shared Perl from $HOME (see later)
perl-local start /path/to/dir # pick up an existing perl-local
installation
# perl -v now reports the local perl
perl-local stop. # system perl (or however your default setup works)
Again, just trying to figure out how to make this as easy as possible for
anyone coming to Perl.
> It feels to me like we need to untangle some concepts here.
>
> First of all there is the question of how and where does a given perl
> get installed.
For the hypothetical perl-local command, maybe something like
./.perl-local/bin. Not too worried so long as it's in the local directory.
(Or $HOME/.perl-local/$name or something like that).
Local directory is great. A shared $HOME Perl would be useful in the way
perlbrew is.
I'm less concerned with how it happens (I'm not qualified to figure out all
of those details), but how easy it is to use. perl-local (or whatever it
might be called) could be created as a CPAN module before core.
Second there is the question of how an app finds that perl.
>
perl-local start /path/to/dir # pick up an existing perl-local
installation
In other words, out of the box, the user *never * has to touch change core
perl because a hypothetical perl-local tool would remove the need for that.
By having it shipped with Perl and highlighted in the README, it would be
easy to get started, rather than hunting around on StackOverflow or
something.
Best,
Ovid
Thread Previous
|
Thread Next