Mailing List Archive

On Tue, 7 Mar 2023 at 10:02, Ovid <curtis.poe@gmail.com> wrote:
> I think the Perl core should consider a solution for this.

What is "this" exactly in your mind? A solution to 'Other languages
bundle tools which allow you to build and install "per-project."'?

You can do that just by running Configure. I have a feeling that you
want something more, but im not sure exactly what it is you want.

> , but ask a sysadmin if they're comfortable running \curl -L https://install.perlbrew.pl | bash and pipe some random website's code to bash.

It is a standard procedure for brew. And lots of languages do it but
substitute github instead of perlbrew.pl. Is this just a matter of
having a version of perlbrew or something similar available on github?

cheersm
yves






--
perl -Mre=debug -e "/just|another|perl|hacker/"

Caveat: I could just be a moron :)

On Tue, Mar 7, 2023 at 10:28?AM demerphq <demerphq@gmail.com> wrote:

> On Tue, 7 Mar 2023 at 10:02, Ovid <curtis.poe@gmail.com> wrote:
> > I think the Perl core should consider a solution for this.
>
> What is "this" exactly in your mind? A solution to 'Other languages
> bundle tools which allow you to build and install "per-project."'?
>
> You can do that just by running Configure. I have a feeling that you
> want something more, but im not sure exactly what it is you want.


There are two parts to this that I see. Yes, I can run ./Configure -des
-Dprefix=$HOME/myperl to install Perl where I want, but perlbrew makes it
trivial to perlbrew switch current-client.

Installing modules per project seems a touch more challenging. Having
something like carton in the code and documented (and suggested) in the
README would make life safer. I have multiple client projects and I want to
be able to cd into a directory and have it easy to know:

1. I'm running the correct version of Perl, along with the correct
configuration
2. Even if something else is using that version, my local modules will
be picked up in preference to my Perl versions.

perlbrew doesn't quite handle the first case. I can run perlbrew install
$version -as my-version, but unless I've misunderstood, I can't have
multiple identical versions of Perl with different configurations. plenv
gives me more freedom, but it's written in bash.


> > , but ask a sysadmin if they're comfortable running \curl -L
> https://install.perlbrew.pl | bash and pipe some random website's code to
> bash.
>
> It is a standard procedure for brew. And lots of languages do it but
> substitute github instead of perlbrew.pl. Is this just a matter of
> having a version of perlbrew or something similar available on github?
>

Fair 'nuff :)

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.

Best,
Ovid

Hi there,

On Tue, 7 Mar 2023, Ovid wrote:

> Caveat: I could just be a moron :)

No, I don't think that. :)

> ...
> 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
> [make a big mess]
> ...
> I think the Perl core should consider a solution for this.

My feelings are that when you've developed something foolproof someone
will come along with a better fool so a Perl core solution won't hold,
and anyway that there are ways to handle this kind of thing already.

I'd be thinking about e.g. a playpen using Docker or Snap, or even VMs.

I've always been pleasantly surprised by the performance I see using
this kind of stuff, you get a lot of extras almost free, and it makes
the control of the installations - assuming anybody cares - a breeze.

--

73,
Ged.

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.

> On Tue, Mar 7, 2023 at 10:28?AM demerphq <demerphq@gmail.com> wrote:
>>
>> On Tue, 7 Mar 2023 at 10:02, Ovid <curtis.poe@gmail.com> wrote:
>> > I think the Perl core should consider a solution for this.
>>
>> What is "this" exactly in your mind? A solution to 'Other languages
>> bundle tools which allow you to build and install "per-project."'?
>>
>> You can do that just by running Configure. I have a feeling that you
>> want something more, but im not sure exactly what it is you want.
>
>
> There are two parts to this that I see. Yes, I can run ./Configure -des -Dprefix=$HOME/myperl to install Perl where I want, but perlbrew makes it trivial to perlbrew switch current-client.

Ageed. I love perlbrew. But others seem to prefer alternatives. It
basically just comes down to what is in your path really. Perlbrew
actually doesn't deal with that that well, try doing "perlbrew use
$a_different_perl; cpanm --look $module", youll find that in the cpanm
shell it is not using the same perl it was after your "perlbrew use"
command.

Im not sure what we could do about this. Maybe we could put some logic
into perl so it checks for an envvar and autoexecs to the correct
version as indicated by the env var. (That would not be hard to do.)

> Installing modules per project seems a touch more challenging. Having something like carton in the code and documented (and suggested) in the README would make life safer. I have multiple client projects and I want to be able to cd into a directory and have it easy to know:
>
> I'm running the correct version of Perl, along with the correct configuration
> Even if something else is using that version, my local modules will be picked up in preference to my Perl versions.

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

> perlbrew doesn't quite handle the first case. I can run perlbrew install $version -as my-version, but unless I've misunderstood, I can't have multiple identical versions of Perl with different configurations. plenv gives me more freedom, but it's written in bash.

Huh? You have definitely misunderstood[1]. Take a look at perlbrew
install-multi. You just have to set the "as" parameter to perlbrew
install, and perlbrew install-multi does that for you.

>>
>> > , but ask a sysadmin if they're comfortable running \curl -L https://install.perlbrew.pl | bash and pipe some random website's code to bash.
>>
>> It is a standard procedure for brew. And lots of languages do it but
>> substitute github instead of perlbrew.pl. Is this just a matter of
>> having a version of perlbrew or something similar available on github?
>
>
> Fair 'nuff :)

I'm really not trying to score smart-ass points here Curtis. :-) I'm
trying to clarify what you want so we can figure out if its is doable
and reasonable.

> 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?

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.

Second there is the question of how an app finds that perl.

So with a system perl it gets installed somewhere by the OS which is
then made available in most users path. With a custom build the perl
gets installed somewhere else, but is intended for all users, and
users must select that perl when they run apps, perhaps by changing
their path. With perlbrew the perl gets installed in your home
directory and is available only for you to use.

So the first could probably be tackled by having some options in
Configure and some standards about where we put "non system but
globally available perls". And maybe some additional rules about how
we set up "per app" perls. The second part is a more complex question.
In theory if your app is installed correctly the .pl scripts should
know the perl they are built against, and should automatically use the
correct perl. However a lot of folks dont install perl scripts though
a CPAN style installation process so they tend to lack this kind of
logic.

Cheers,
yves


[1] My perlbrew installed perls.
$ perlbrew list
blead_NSA
blead_SA
perl-5.37.9
perl-5.37.9-debug
perl-5.37.9-thread-multi
perl-5.37.9-thread-multi-debug
perl-5.37.8
perl-5.37.8-debug
perl-5.37.8-thread-multi
perl-5.37.8-thread-multi-debug
perl-5.37.7
perl-5.37.7-debug
perl-5.37.7-thread-multi
perl-5.37.7-thread-multi-debug
perl-5.37.6
perl-5.37.6-debug
perl-5.37.6-thread-multi
perl-5.37.6-thread-multi-debug
perl-5.37.5
perl-5.37.5-debug
perl-5.37.5-thread-multi
perl-5.37.5-thread-multi-debug
longdouble_blead
perl-5.37.4
perl-5.37.4-debug
perl-5.37.4-thread-multi
perl-5.37.4-thread-multi-debug
quadmath_blead
stop_first_error
perl-5.37.3
perl-5.37.3-debug
perl-5.37.3-thread-multi
perl-5.37.3-thread-multi-debug
perl-5.37.2
perl-5.37.2-debug
perl-5.37.2-thread-multi
perl-5.37.2-thread-multi-debug
perl-5.37.1
perl-5.37.1-debug
perl-5.37.1-thread-multi
perl-5.37.1-thread-multi-debug
latest_blead
latest_blead_nd
perl-5.37.0
perl-5.37.0-debug
perl-5.37.0-thread-multi
perl-5.37.0-thread-multi-debug
perl_no_rc_stack
perl_rc_stack
perl-5.36.0
perl-5.36.0-debug
perl-5.36.0-thread-multi
perl-5.36.0-thread-multi-debug
perl-5.35.10
perl-5.35.10-debug
perl-5.35.10-thread-multi
perl-5.35.10-thread-multi-debug
* perl-5.34.1
perl-5.34.1-debug
perl-5.34.1-thread-multi
perl-5.34.1-thread-multi-debug
perl-5.32.1
perl-5.32.1-debug
perl-5.32.1-thread-multi
perl-5.32.1-thread-multi-debug
perl-5.30.3
perl-5.30.3-debug
perl-5.30.3-thread-multi
perl-5.30.3-thread-multi-debug
perl-5.28.3
perl-5.28.3-debug
perl-5.28.3-thread-multi
perl-5.28.3-thread-multi-debug
perl-5.26.3
perl-5.26.3-debug
perl-5.26.3-thread-multi
perl-5.26.3-thread-multi-debug
perl-5.24.4
perl-5.24.4-debug
perl-5.24.4-thread-multi
perl-5.24.4-thread-multi-debug
perl-5.22.4
perl-5.22.4-debug
perl-5.22.4-thread-multi
perl-5.22.4-thread-multi-debug
perl-5.20.3
perl-5.20.3-debug
perl-5.20.3-thread-multi
perl-5.20.3-thread-multi-debug
perl-5.18.4
perl-5.18.4-debug
perl-5.18.4-thread-multi
perl-5.18.4-thread-multi-debug
perl-5.16.3
perl-5.16.3-debug
perl-5.16.3-thread-multi
perl-5.16.3-thread-multi-debug
perl-5.14.4
perl-5.14.4-debug
perl-5.14.4-thread-multi
perl-5.14.4-thread-multi-debug
perl-5.12.5
perl-5.12.5-debug
perl-5.12.5-thread-multi
perl-5.12.5-thread-multi-debug
perl-5.10.1
perl-5.10.1-debug
perl-5.10.1-thread-multi
perl-5.10.1-thread-multi-debug
perl-5.8.9
perl-5.8.9-debug
perl-5.8.9-thread-multi
perl-5.8.9-thread-multi-debug
perl-5.6.2
perl-5.6.2-debug
perl-5.6.2-thread-multi
perl-5.6.2-thread-multi-debug

--
perl -Mre=debug -e "/just|another|perl|hacker/"

? 2023?3?7? ??6:57:12 [GMT+09:00]?
> I have multiple client projects and I want to
>be able to cd into a directory and have it easy to know:
>
> 1. I'm running the correct version of Perl, along with the correct
> configuration
>



I've been non-decisive about whether such feature should be part of perlbrew, or be left as an exercise of its users.

At some point `rvm` (for ruby) defines a `cd` shell function that are able to auto-switch to project-specific version of ruby installation whenever you `cd` into some ruby project dir, and undo so whenevere you cd out of it.

I found this a great idea, but not something I wish to do for once reason -- I do projects in multilpe programming languages and if several of those tools redefine `cd`... I doubt that I could still have a workable shell in front of me.

I imagine a more workable, non-intrusive, solution is something like this

1. Add `.bin` to $PATH (relative path)
2. Add `.bin/perl` that is a shim script, in which PERL5LIB, PATH, and other envs are tweaked and eventually a line of `exec perl` at the end.

Having relative path in $PATH is probably as contraversial as `curl | bash` though.


OTOH if it's ok not to make it looks `magic`, I don't see why we couldn't put a copy of relocatable perl under ".local/bin/perl" and have some basic, per-project shell wraper for tweaking envs.

--
Kang-min Liu

Op 07-03-2023 om 11:12 schreef G.W. Haywood via perl5-porters:
> Hi there,
>
> On Tue, 7 Mar 2023, Ovid wrote:
>
>
> I'd be thinking about e.g. a playpen using Docker or Snap, or even VMs.
>
>

My employer uses Docker for this and it has been the best ding they ever
did for Perl (and other) projects. Makes lots of problems just disapear.


HTH,

M4

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

On Tue, Mar 7, 2023 at 12:40?PM Martijn Lievaart <m@rtij.nl> wrote:

> My employer uses Docker for this and it has been the best ding they ever
> did for Perl (and other) projects. Makes lots of problems just disapear.
>

Yup. Docker is amazing, but not everyone wants to use Docker. I'm on a Mac
and using Docker on a Mac is painful. When clients provide me with Docker,
it makes life easy, but the code runs like cold molasses (you can hit your
favorite search engines for tons of ways to try to fix this and tear your
hair out in the process).

By having a native, local Perl solution, we can provide a solution that
other languages provide and the core solution would probably serve most
needs. When, and if, someone needs more, they'd hopefully have more
experience in understanding their needs and finding a better solution.

Cheers,
Ovid

On Tue, 7 Mar 2023 12:40:42 +0100, Martijn Lievaart <m@rtij.nl> wrote:

> Op 07-03-2023 om 11:12 schreef G.W. Haywood via perl5-porters:
> > Hi there,
> >
> > On Tue, 7 Mar 2023, Ovid wrote:
> >
> >
> > I'd be thinking about e.g. a playpen using Docker or Snap, or even VMs.
>
> My employer uses Docker for this and it has been the best ding they ever
> did for Perl (and other) projects. Makes lots of problems just disapear.

In many cases docker helps. Sometimes a lot.

In many other cases it is just a tool to move your problems to other
parts of the system: docker uses storage in a way that makes it a lot
harder to clean up tmp space and or log files without losing
information. When disk-space is shared with the host for
data-persistency, user ID's, access-rights and backup-strategies arise
as new issues.

Another problem is that once docker was declared as "the solution" for
one problem, teams that use it are likely to put all kinds of stuff in
docker and ignore the added complexity and burden on system maintainers
and likely more network overhead and administration overhead. Last but
not least: docker users tend to want docker to run a specific version
of software not supported by the docker host. (one of the best reasons
to use docker imho), but that require a certain version of docker to
run that where that version of docker (and/or docker-compose) is *also*
not supported on that host. Now the fact that the software won't run
suddenly is someone elses problem.

FWIW I've seen docker use with log files over 50 Gb per day just
because they didn't look into logging and then the host wen out of disk
space because nobody cared to monitor the host. It's in docker now, it
starts, it runs, so my problem is gone.

> HTH,
>
> M4

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

On Tue, Mar 7, 2023 at 4:57?AM Ovid <curtis.poe@gmail.com> wrote:
> 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.
>
> Best,
> Ovid

This is the use case that App::MechaCPAN was designed for: producing a
completely self contained local/. It has no non-core dependencies, can
build and install a perl binary into local/, and by default will
automatically include local/ and lib/ into @INC.

https://metacpan.org/pod/App::MechaCPAN

-Jon Gentle

tl;dr plenv seems to be close to what you want

On Tue, Mar 07, 2023 at 10:57:12AM +0100, Ovid wrote:
> On Tue, Mar 7, 2023 at 10:28?AM demerphq <demerphq@gmail.com> wrote:
> > On Tue, 7 Mar 2023 at 10:02, Ovid <curtis.poe@gmail.com> wrote:

> > > I think the Perl core should consider a solution for this.
> >
> > What is "this" exactly in your mind? A solution to 'Other languages
> > bundle tools which allow you to build and install "per-project."'?
> >
> > You can do that just by running Configure. I have a feeling that you
> > want something more, but im not sure exactly what it is you want.

> There are two parts to this that I see. Yes, I can run ./Configure -des
> -Dprefix=$HOME/myperl to install Perl where I want, but perlbrew makes it
> trivial to perlbrew switch current-client.

AIUI perlbrew let you select a global perl version to use,
allows you to launch a *shell* running a different perl, but
not to specify a perl version for a particular directory.

> Installing modules per project seems a touch more challenging. Having
> something like carton in the code and documented (and suggested) in the
> README would make life safer. I have multiple client projects and I want to
> be able to cd into a directory and have it easy to know:

> 1. I'm running the correct version of Perl, along with the correct
> configuration

Maybe have some sort of file in that directory as an
indicator which perl version to use. plenv uses .perl-version.

> 2. Even if something else is using that version, my local modules will
> be picked up in preference to my Perl versions.

plenv-contrib(1) adds commands to set up a local::lib for a
particular perl version. You can launch a shell with a
selected perl-version/local::lib combination.

plenv use 5.18.0
plenv lib create 5.16.3@nobita
plenv use 5.16.3@nobita

> perlbrew doesn't quite handle the first case. I can run perlbrew install
> $version -as my-version, but unless I've misunderstood, I can't have
> multiple identical versions of Perl with different configurations. plenv
> gives me more freedom, but it's written in bash.

Being written in bash isn't much of an obstacle. It's small,
a hundred lines. The actual installer Build::Perl *does*
take many options, is pure perl, and is accessible through
plenv.

plenv also makes minimal changes to the environment compared
to perlbrew: just one addition to PATH.

> Fair 'nuff :)
>
> 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.

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

--
Joel Roth

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,
Ovid

On Wed, 8 Mar 2023 at 08:41, Ovid <curtis.poe@gmail.com> wrote:
>
> 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:
>
>> 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.

Id put it the exact opposite than you have. I think Perl has a very
strong tradition and bias towards treating all software as libraries
(which i think is that they mean by "development tool"), so I think
what we do well is the development tooling part. However I think we
do library management so well that we end up forgetting there is a big
difference between an application and a library. To the point where we
often bundle applications /as/ libraries, and then try to shoehorn
them together into the same management tooling and space. Our support
for programs and applications is pretty poor. We could definitely do
better there. But note that is the opposite of what you said, and is
actually more aligned with the paragraph you quote. I think that
paragraph is right that we do tend to blur the line between some of
the things they mention. We treat applications as libraries that are
configured, instead of programs that are supported by specific
libraries. A subtle but key distinction.

> 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?

It still isn't really clear to me that core needs to be involved here.
Maybe it can be and maybe it should be, but I am not clear on what and
where. We simply dont think about programs very much, we are so
strongly biased towards all the world being a library that we tend to
convert our programs into libraries so they can fit into that space.
What we need to do to support *programs* in core isn't clear to me at
all. I definitely would like to see the Perl community as a whole
think about programs as distinct from libraries, but it isn't clear to
me if that means achieving consensus on what differs between a program
and a library, or if it means actual code changes to core. If it does
mean changes to core I am interested using my skills to help solve the
problem. but I think this subject needs a lot more gestation before we
get to that point.

We should do some brain-storming on this what do we think is different
between "program think" and "library think". Here is an initial
contribution:

A program wants to own its dependency chain. It doesn't want to have
to work with every version of a library ever published, it wants to be
run against a specific version of a library. Compare to library
think, which IMO is the opposite. With library-think there is an
incentive to try to make every library work with as many released
versions of perl as possible because your library might be installed
into any number of different perls. With application-think you dont
care about new perl releases, you just care that your application
works with the version of perl it was intended to work with.

This goes against our model of a unified library tree. If we thought
more "program" like we would not have a standard library tree which
everything gets installed into, we would have a per application
library tree, and we would make it easier for a perl program to
control its libraries. This means that we probably should not support
as many varieties of layout of libraries. Eg versioned library trees,
etc. We should probably ditch some of the build modes we support and
only support the simple per perl library tree. This has been the
tendency of the community for some time, but we still have vestigal
support for using the same library with multiple perls, and we still
have the vestigal concept that library trees are not relocatable, etc
(although we have support for relocatable lib, its opt-in).

If there are K programs on someones box that are built out of Perl
should there be K perl binaries used? From a program-think perspective
probably yes, although maybe it would make sense to have a way to
share the perl binary across multiple apps that are intended to target
that version of perl. That means we should ditch or extend the idea of
a "standard location" for the perl binary, and we should probably move
away from the notion that you just stick perl/bin into your path and
let all your scripts run against the standard perl. It would also
eliminate all the issues with "system perl" versus "customized perl".
So if we are going to change this we probably need to really rethink
how things like Configure work in terms of these build options.

IMO there is a lot to think about before we actually understand what
needs to change in core. But I do think this is something worth doing.
The fact we have perlbrew, plenv, local::lib, and so much other
support along these lines suggests we are doing something wrong. I
think the first step is to realize realize that our success in
managing *libraries* has not translated into success managing
applications, and in fact that our strong library bias has played
against us in the long run. That is a sentiment I definitely agree
with. If we can start with the premise that we do programs wrong, then
we can start reasoning about how to do them right.

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Wed, Mar 8, 2023 at 11:56?AM demerphq <demerphq@gmail.com> wrote:

> However I think we
> do library management so well that we end up forgetting there is a big
> difference between an application and a library.


This is a very good perspective and not quite aligned with what I was
thinking (not a bad thing). I was trying to solve the problem that we don't
support development well (sorry, we don't, and the plethora of solutions
shows this) and I want to fix that. But instead of development versus
production, you're talking about libraries versus applications. So we have:

Applications
|
Dev -----+------ Prod
|
Libraries

In the above perspective, we actually have four problem spaces to address,
each of which can have subtly different requirements. If I'm writing a
library, being able to run perlbrew exec perl myprogram.pl against all
installed versions is pretty awesome. If I'm writing an application, it's
pretty useless.

From that point of view, it would be a matter of sussing out what is needed
in each of those spaces and ask what we support and what should core Perl
support. For a user story:

1. As a developer
2. I want to easily set up multiple isolated Perl environments
3. So I can support multiple isolated clients/projects
4. Because my work shouldn't have the fragility of picking up the wrong
dependencies

The last point bit me a couple of hours ago when I discovered a client's
locally-copied URI library was 1.74, but I was using 5.17. Oops.

I don't think that story is too far from what you're saying?

(I should point out that we might have eight problem spaces if we add
producer/consumer. If I'm consuming a library, I would love to know if it's
really the library I intended, but Perl doesn't support that. I probably
have fewer qualms about an application because it's easier to know where I
got the application from (caveat emptor). But I don't think that's
solvable—at least right now)

As for the switch to looking at things from the application standpoint, I
got nuthin', but I agree with your point that ...


> We treat applications as libraries that are
> configured, instead of programs that are supported by specific
> libraries. A subtle but key distinction.


Getting back to:

It still isn't really clear to me that core needs to be involved here.
>

If we look at it from the standpoint of my user story, I think core *should* be
involved because I want to download and install Perl and already have the
primary tool necessary to implement that story.


> We should do some brain-storming on this what do we think is different
> between "program think" and "library think".


And "dev think" versus "prod think."


> Here is an initial
> contribution:
>
> A program wants to own its dependency chain. It doesn't want to have
> to work with every version of a library ever published, it wants to be
> run against a specific version of a library. Compare to library
> think, which IMO is the opposite. With library-think there is an
> incentive to try to make every library work with as many released
> versions of perl as possible because your library might be installed
> into any number of different perls. With application-think you dont
> care about new perl releases, you just care that your application
> works with the version of perl it was intended to work with.
>

Yup. That's what I want, but I got there from a different starting point.
However, beyond that, I also have no clear idea about the application space.


> The fact we have perlbrew, plenv, local::lib, and so much other
> support along these lines suggests we are doing something wrong.


Agreed, but I think we're in a good place to start because there's so much
prior art. The first step in the OODA (Observe, Orient, Decide, Act) is to
observe. So listing all of the Perl tools that generally fall into the
simple model I showed above would be good. It would also be worth looking
at success/failure modes of other language's tooling which fills a similar
niche (I'm looking at you, leftpad
<https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code>
).


> If we can start with the premise that we do programs wrong, then
> we can start reasoning about how to do them right.
>

That's certainly not something I have answers for, but these do seem to be
closely related problems.

(If it sounds like I'm talking past you (I have no idea), it's probably
because I've misunderstood something. My apologies in advance)

Best,
Ovid

On Wed, 8 Mar 2023 at 13:29, Ovid <curtis.poe@gmail.com> wrote:
>
> On Wed, Mar 8, 2023 at 11:56?AM demerphq <demerphq@gmail.com> wrote:
>>
>> However I think we
>> do library management so well that we end up forgetting there is a big
>> difference between an application and a library.
>
>
> This is a very good perspective and not quite aligned with what I was thinking (not a bad thing). I was trying to solve the problem that we don't support development well (sorry, we don't, and the plethora of solutions shows this)

Well, I suspect you and I are using "development" in a different way
then, because in the way I understand development I don't agree with
you. I think we support the development of libraries very well. :-)

> and I want to fix that. But instead of development versus production, you're talking about libraries versus applications. So we have:
>
> Applications
> |
> Dev -----+------ Prod
> |
> Libraries
>
> In the above perspective, we actually have four problem spaces to address, each of which can have subtly different requirements. If I'm writing a library, being able to run perlbrew exec perl myprogram.pl against all installed versions is pretty awesome. If I'm writing an application, it's pretty useless.

I dont really follow your division on dev/prod here (meaning I
literally dont understand the difference you are making, not that I
dont agree with you, if I understood the distinction I might agree, or
might not). But i agree with you about library vs application. :-)

What do you mean by "development" here in terms of a simple example
like the one about "against all installed versions"?

> From that point of view, it would be a matter of sussing out what is needed in each of those spaces and ask what we support and what should core Perl support. For a user story:
>
> 1. As a developer
> 2. I want to easily set up multiple isolated Perl environments
> 3. So I can support multiple isolated clients/projects
> 4. Because my work shouldn't have the fragility of picking up the wrong dependencies

Ok, but to me this is basically exactly what i would say as an
"application developer", but not what i would say as a "library
developer". :-) From the POV of application developer I 100% agree
with you btw.

> The last point bit me a couple of hours ago when I discovered a client's locally-copied URI library was 1.74, but I was using 5.17. Oops.

:-)

> I don't think that story is too far from what you're saying?

Agreed. If you just remove the dev/prod axis on your chart we are
totally on the same page.

To me "developer activity" is distinct depending on whether I am
working on a library or an applicaton. For instance, to me "author
testing" is development activity for a library author, to for instance
test something like whether the code is warning free. But "author
testing" in an application context would be something like unit tests
for undocumented internal application specific code, as opposed to say
PRT (production readiness testing) for the APP to ensure it is
behaving as it is documented.

> (I should point out that we might have eight problem spaces if we add producer/consumer. If I'm consuming a library, I would love to know if it's really the library I intended, but Perl doesn't support that.

Can you expand on what you mean by that?

> I probably have fewer qualms about an application because it's easier to know where I got the application from (caveat emptor). But I don't think that's solvable—at least right now)

And on that?

>
> As for the switch to looking at things from the application standpoint, I got nuthin', but I agree with your point that ...
>
>>
>> We treat applications as libraries that are
>> configured, instead of programs that are supported by specific
>> libraries. A subtle but key distinction.
>
>
> Getting back to:
>
>> It still isn't really clear to me that core needs to be involved here.
>
>
> If we look at it from the standpoint of my user story, I think core should be involved because I want to download and install Perl and already have the primary tool necessary to implement that story.

So i /think/ what you mean by that is you want to download and install
perl in a way that we do not currently really support out of the box.
Not as a generic site wide installation on the computer in question,
but as an application specific installation which should have no
exposure to any other application or software installed on the box.

>>
>> We should do some brain-storming on this what do we think is different
>> between "program think" and "library think".
>
>
> And "dev think" versus "prod think."

Id really like you to spell out what you have in mind there. It is
really not clear what you mean to me. When I think about this problems
the disctinction between prod and dev is much more conditional on the
other axis than it is on prod vesus dev.

>>
>> Here is an initial
>> contribution:
>>
>> A program wants to own its dependency chain. It doesn't want to have
>> to work with every version of a library ever published, it wants to be
>> run against a specific version of a library. Compare to library
>> think, which IMO is the opposite. With library-think there is an
>> incentive to try to make every library work with as many released
>> versions of perl as possible because your library might be installed
>> into any number of different perls. With application-think you dont
>> care about new perl releases, you just care that your application
>> works with the version of perl it was intended to work with.
>
>
> Yup. That's what I want, but I got there from a different starting point. However, beyond that, I also have no clear idea about the application space.

Ok.

>>
>> The fact we have perlbrew, plenv, local::lib, and so much other
>> support along these lines suggests we are doing something wrong.
>
>
> Agreed, but I think we're in a good place to start because there's so much prior art. The first step in the OODA (Observe, Orient, Decide, Act) is to observe. So listing all of the Perl tools that generally fall into the simple model I showed above would be good. It would also be worth looking at success/failure modes of other language's tooling which fills a similar niche (I'm looking at you, leftpad).

Agreed. OODA is a good model. ++ for mentioning it. (Just because it
is an army thing doesn't mean it isnt useful!)

>>
>> If we can start with the premise that we do programs wrong, then
>> we can start reasoning about how to do them right.
>
>
> That's certainly not something I have answers for, but these do seem to be closely related problems.
>
> (If it sounds like I'm talking past you (I have no idea), it's probably because I've misunderstood something. My apologies in advance)

No you don't sound like you are talking past me, I think anyway. :-)

The only thing I dont really follow is the distinction you are making
between prod and dev. You seem to feel very strongly that we do
"development" badly. I feel that is one of the things we do really
well. So somewhere there is a disconnect between our two perspectives
that might come out in the wash with a better set of definitions.

However it seems to me that we are pretty much on the same page
otherwise: We both agree that we in perl land have an overly "library"
oriented mentality, and do not serve the "application development"
model very well. We also seem to agree that the plethora of tooling
available to help with this suggests that core itself is missing
something important.

Yves



--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Wed, 8 Mar 2023 at 14:19, demerphq <demerphq@gmail.com> wrote:
> > If we look at it from the standpoint of my user story, I think core should be involved because I want to download and install Perl and already have the primary tool necessary to implement that story.
>
> So i /think/ what you mean by that is you want to download and install
> perl in a way that we do not currently really support out of the box.
> Not as a generic site wide installation on the computer in question,
> but as an application specific installation which should have no
> exposure to any other application or software installed on the box.

I was trying to think about "what would be different for an
application perl and a site-wide perl", and here is what i came up
with:

1. In an application perl most of the environment variables understood
by perl should *not* randomly come from the environment. They should
probably come from a specific configuration file which is private to
and owned by the application only.
2. In an application perl none of the libraries should come "from the
perl" they should come from the application itself. There should be
no "site_perl" directory, nor "lib" directory built in. CPAN should
never install modules into the perls trees, and should not even be
usable with it. (Modulo maybe modules required to implement internal
features of that perl, for instance the NamedCapture ties that we used
to have implemented as perl modules)
3. There should be no perlbug or other utilities installed with the
perl except those that come with the application.
4. All features where a perl knows to execute another perl should be
disabled. If an application is intended to be run against a specific
perl executable that perl executable shouldnt be tricked into spawning
another perl.
5. Features like taint, and whatnot should be compiled out, or in,
depending on the applications needs.

This isnt an exhaustive list btw, just trying to think this through.
yves

On Wed, Mar 8, 2023 at 2:19?PM demerphq <demerphq@gmail.com> wrote:

> What do you mean by "development" here in terms of a simple example

like the one about "against all installed versions"?


Imagine we0 have a perl-local tool. Let's say I'm working for Acme corp. I
check out a repo from Acme corp's git and I see they support perl-locale,
so I use it. The following is hypothetical interface and would
need tweaking.

git clone $some_repo
cd acme-kill-all-the-squirrels
perl-local switch . # my perl is now set to use the local perl-local
setup
perl-local setup # builds Perl with proper config and version
# installs required cpan modules
<hack hack hack>
git commit -av
git push

When I git push, I obviously don't want my CPAN modules or perl executable
pushed, even if they're int he same directory. They're probably added to a
.gitignore file. However, having the executable and CPAN modules in the
same directory means that when I'm finished with this client, I can
probably just rm -fr acme-kill-all-the-squirrels and I'm good to go. This
not only keeps some paranoid clients happy, but I also don't have the usual
hunting around on my computer trying to remember where custom stuff is
installed. It's all in that one directory.

So what I'm using for development is kept local, it's only for the one
project, and it's not pushed to the client.


> > I don't think that story is too far from what you're saying?
>
> Agreed. If you just remove the dev/prod axis on your chart we are
> totally on the same page.


Happy to do that.


> > (I should point out that we might have eight problem spaces if we add
> producer/consumer. If I'm consuming a library, I would love to know if it's
> really the library I intended, but Perl doesn't support that.
>

> Can you expand on what you mean by that?
>

Decades ago I was working on a project where our installed version of
CGI.pm was found to have some local hacks for file uploads. We needed to
update CGI.pm, but it wasn't clear what the hacks were trying to fix, or if
upgrading would break things. (worse, finding out that someone has
maliciously changed a CPAN module would be bad).

It would be nice to have something in a cpanfile (or something similar),
which does this:

requires Some::Module => '== v1.2.3',
digest => '922547e866c89b8f677312df0ccec8ee';

In other words, it locks down the version and the app can throw an
exception if the digest doesn't match.

Or better, there's a trusted source of digests and:

verified Some::Module => 'v1.2.3';

And that would consult the source, figure out what version of Some::Module
is installed and verify the digest. Of course, it would need to do that for
all CPAN modules in the project. That might be awfully hard if we try to
run that against system Perl (especially if vendors are change the code). I
suspect there are a few devils in the details, but just because I have
Some::Module installed doesn't mean it's the Some::Module from the CPAN.

> I probably have fewer qualms about an application because it's easier to
> know where I got the application from (caveat emptor). But I don't think
> that's solvable—at least right now)
>
> And on that?


I download something from the App store from a trusted vendor and I just
don't worry too much about it (some would tell me that's stupid).


>

So i /think/ what you mean by that is you want to download and install
> perl in a way that we do not currently really support out of the box.
> Not as a generic site wide installation on the computer in question,
> but as an application specific installation which should have no
> exposure to any other application or software installed on the box.
>

As much as is possible, yes.


> > And "dev think" versus "prod think."
>
> Id really like you to spell out what you have in mind there. It is
> really not clear what you mean to me.


I hope I explained it above. We do dev well for someone writing a library,
but not for a client/product/app. So I think we're talking more or less
about the same thing.

Best,
Ovid

On Wed, 8 Mar 2023 at 15:18, Ovid <curtis.poe@gmail.com> wrote:
>
> On Wed, Mar 8, 2023 at 2:19?PM demerphq <demerphq@gmail.com> wrote:
>>
>> What do you mean by "development" here in terms of a simple example
>>
>> like the one about "against all installed versions"?
>
>
> Imagine we0 have a perl-local tool. Let's say I'm working for Acme corp. I check out a repo from Acme corp's git and I see they support perl-locale, so I use it. The following is hypothetical interface and would need tweaking.
>
> git clone $some_repo
> cd acme-kill-all-the-squirrels
> perl-local switch . # my perl is now set to use the local perl-local setup
> perl-local setup # builds Perl with proper config and version
> # installs required cpan modules
> <hack hack hack>
> git commit -av
> git push
>
> When I git push, I obviously don't want my CPAN modules or perl executable pushed, even if they're int he same directory. They're probably added to a .gitignore file. However, having the executable and CPAN modules in the same directory means that when I'm finished with this client, I can probably just rm -fr acme-kill-all-the-squirrels and I'm good to go. This not only keeps some paranoid clients happy, but I also don't have the usual hunting around on my computer trying to remember where custom stuff is installed. It's all in that one directory.
>
> So what I'm using for development is kept local, it's only for the one project, and it's not pushed to the client.

Ok, I have some reservations about the the perl-local switch bit, but
that is an implementation detail we can deal with some other time. I
get what you are saying here.

>>
>> > I don't think that story is too far from what you're saying?
>>
>> Agreed. If you just remove the dev/prod axis on your chart we are
>> totally on the same page.
>
>
> Happy to do that.
>
>>
>> > (I should point out that we might have eight problem spaces if we add producer/consumer. If I'm consuming a library, I would love to know if it's really the library I intended, but Perl doesn't support that.
>>
>>
>> Can you expand on what you mean by that?
>
>
> Decades ago I was working on a project where our installed version of CGI.pm was found to have some local hacks for file uploads. We needed to update CGI.pm, but it wasn't clear what the hacks were trying to fix, or if upgrading would break things. (worse, finding out that someone has maliciously changed a CPAN module would be bad).
>
> It would be nice to have something in a cpanfile (or something similar), which does this:
>
> requires Some::Module => '== v1.2.3',
> digest => '922547e866c89b8f677312df0ccec8ee';
>
> In other words, it locks down the version and the app can throw an exception if the digest doesn't match.
>
> Or better, there's a trusted source of digests and:
>
> verified Some::Module => 'v1.2.3';
>
> And that would consult the source, figure out what version of Some::Module is installed and verify the digest. Of course, it would need to do that for all CPAN modules in the project. That might be awfully hard if we try to run that against system Perl (especially if vendors are change the code). I suspect there are a few devils in the details, but just because I have Some::Module installed doesn't mean it's the Some::Module from the CPAN.

Hmm. Yes I get you. With the __REQUIRE__ hook I want to add to perl
this would be trivial to implement in a plug in way. I will look
further into this one. It gets a bit interesting when you factor in
source filters, but it is still doable IMO.

See: https://github.com/Perl/perl5/pull/20637

>> > I probably have fewer qualms about an application because it's easier to know where I got the application from (caveat emptor). But I don't think that's solvable—at least right now)
>>
>> And on that?
>
>
> I download something from the App store from a trusted vendor and I just don't worry too much about it (some would tell me that's stupid).

Ok. I think I follow.

>>
>>
>>
>> So i /think/ what you mean by that is you want to download and install
>> perl in a way that we do not currently really support out of the box.
>> Not as a generic site wide installation on the computer in question,
>> but as an application specific installation which should have no
>> exposure to any other application or software installed on the box.
>
>
> As much as is possible, yes.
>
>>
>> > And "dev think" versus "prod think."
>>
>> Id really like you to spell out what you have in mind there. It is
>> really not clear what you mean to me.
>
>
> I hope I explained it above. We do dev well for someone writing a library, but not for a client/product/app. So I think we're talking more or less about the same thing.

I think so. I still think the main distinction comes down to the
"library" versus "script" versus "application". (Where a "script" sits
in between the two.) But i think the important points we agree on.

I definitely think we can do better to support applications as
distinct from site-wide installs. I am happy to help out on this, I
think it is worthy goal. I think convincing the wider ecosystem that
it makes sense to do this, and then getting the various actors to do
their bits as well. Perl is a big ship and turning it around takes a
lot of sea-room and there are a lot of actors that can slow the
process down a lot.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Wed, Mar 8, 2023 at 3:38?PM demerphq <demerphq@gmail.com> wrote:

> > Or better, there's a trusted source of digests and:
> >
> > verified Some::Module => 'v1.2.3';
> >
> > And that would consult the source, figure out what version of
> Some::Module is installed and verify the digest. Of course, it would need
> to do that for all CPAN modules in the project. That might be awfully hard
> if we try to run that against system Perl (especially if vendors are change
> the code). I suspect there are a few devils in the details, but just
> because I have Some::Module installed doesn't mean it's the Some::Module
> from the CPAN.
>
> Hmm. Yes I get you. With the __REQUIRE__ hook I want to add to perl
> this would be trivial to implement in a plug in way. I will look
> further into this one. It gets a bit interesting when you factor in
> source filters, but it is still doable IMO.
>

You know, I just realized this would also help with a long-standing issue.
I've had various clients forbid certain modules. Some modules may not be
used directly in client code, and some must not be even used indirectly
because the author's done something really naughty. You pull in Mega::Module
which loads half of the CPAN and don't notice you have the naughty module,
well, now it will be easier in a central place to drop in:

# syntax is bad, but shows the concept
forbids 'Naughty::Module';
forbids 'Other::Module' => [ '<' => v1.2.3 ];
forbids 'Buggy::Version' => [ '1.4..1.7', '2.3' ];

Probably a lot of this stuff would be marginal value for most, but some of
my larger clients, I have some very specific modules in mind which must
never be loaded.

Best,
Ovid

On 2023-03-07 10:01, Ovid wrote:
> 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.

See also: https://direnv.net/

-- Ruud

> On Mar 8, 2023, at 6:18 AM, Ovid <curtis.poe@gmail.com> wrote:
>
> git clone $some_repo
> cd acme-kill-all-the-squirrels
> perl-local switch . # my perl is now set to use the local perl-local setup
> perl-local setup # builds Perl with proper config and version
> # installs required cpan modules
> <hack hack hack>
> git commit -av
> git push
>
> When I git push, I obviously don't want my CPAN modules or perl executable pushed, even if they're int he same directory. They're probably added to a .gitignore file. However, having the executable and CPAN modules in the same directory means that when I'm finished with this client, I can probably just rm -fr acme-kill-all-the-squirrels and I'm good to go. This not only keeps some paranoid clients happy, but I also don't have the usual hunting around on my computer trying to remember where custom stuff is installed. It's all in that one directory.

FWIW: I have pretty much this exact workflow when working with plenv+Carton or perlbrew+Carton (or system-perl+Carton) but it requires having designed for that in my dev environment setup. When client's _haven't_ made sure they're supporting a process which is perl-install agnostic, that's when things get rough. Usually it's because they've organically grown their application for over a decade and "just didn't know better", which is fair … I'm not sure I was using Carton as heavily in 2013 as I am today.

-Chris

* Ruud H.G. van Tol via perl5-porters <perl5-porters@perl.org> [2023-03-14 10:50:48 +0100]:

>
> On 2023-03-07 10:01, Ovid wrote:
> > 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.
>
> See also: https://direnv.net/

It is also worth pointing out that one may create a properly isolated shell environment
with custom PATHs, aliases, and bash functions by using the following bash option, --rcfile:

exec bash --rcfile path/to/some/file.rc

I use a similar line in a wrapper script I have that provides a completely isolated Perl
environment, but it effectively allows one to have an overlay environment.

For example, I use it to:

1. contain a full perl installation (installed initially via perlbrew, probably unnecessarily)
2. install modules via cpanm, that was itself installed via "perlbrew --install-cpanm"
3. retain access to system python2/3
4. maintain an exclusive bin, lib, include directories for different src I build

For an interactive environment, this works great. I am not sure how this would work out in
start up script or something else non-interactive, but I suspect bash would be quite happy
taking an --rcfile in most situations.

The nice part is that I can easily enter this environment or exit it, depending on my needs.
It also makes it pretty easy to create a portable environment from system to system, that
environment being the one created by your custom rcfile.

Cheers,
Brett

>
> -- Ruud
>

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Mar 14, 2023 at 5:51?PM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> For an interactive environment, this works great. I am not sure how this
> would work out in
> start up script or something else non-interactive, but I suspect bash
> would be quite happy
> taking an --rcfile in most situations.
>

Is this just to show how others approach this? Having a core Perl solution
relying on bash seems problematic, especially given Windows. Is that an
option? I haven't done anything serious with Windows in two decades, so my
knowledge is seriously out-of-date.

Best,
Ovid

On Tue, 14 Mar 2023 at 17:51, Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> * Ruud H.G. van Tol via perl5-porters <perl5-porters@perl.org>
> [2023-03-14 10:50:48 +0100]:
>
> >
> > On 2023-03-07 10:01, Ovid wrote:
> > > 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.
> >
> > See also: https://direnv.net/
>
> It is also worth pointing out that one may create a properly isolated
> shell environment
> with custom PATHs, aliases, and bash functions by using the following bash
> option, --rcfile:
>
> exec bash --rcfile path/to/some/file.rc
>
> I use a similar line in a wrapper script I have that provides a completely
> isolated Perl
> environment, but it effectively allows one to have an overlay environment.
>
> For example, I use it to:
>
> 1. contain a full perl installation (installed initially via perlbrew,
> probably unnecessarily)
> 2. install modules via cpanm, that was itself installed via "perlbrew
> --install-cpanm"
> 3. retain access to system python2/3
> 4. maintain an exclusive bin, lib, include directories for different src I
> build
>
> For an interactive environment, this works great. I am not sure how this
> would work out in
> start up script or something else non-interactive, but I suspect bash
> would be quite happy
> taking an --rcfile in most situations.
>
> The nice part is that I can easily enter this environment or exit it,
> depending on my needs.
> It also makes it pretty easy to create a portable environment from system
> to system, that
> environment being the one created by your custom rcfile.
>

Note that a solution that depends on /bash/ isn't really a solution. It's a
platform specific workaround. We target lots of platforms, at least a few
of which do not use bash.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"