Mailing List Archive

* Ovid <curtis.poe@gmail.com> [2023-03-14 18:13:19 +0100]:

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

You snipped out the relevant part of the RT message. And who brought up Windows?

I'm trying to understand the issue better, in particular what is lacking in environmental
variable or module support needed to make perl "portable" or "relocatable" as it
stands?

There are a variety of ways to manage one's shell environment, bash's "--rcfile" is
yet another one.

Ultimately, sounds like you got a client in a pickle and are trying to figure out
where Perl can help, which is fair. So I am trying to get clarification on what
you're wanting Perl do to make up for your own clients mess.

Cheers,
Brett

>
> Best,
> Ovid

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

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

> * Ovid <curtis.poe@gmail.com> [2023-03-14 18:13:19 +0100]:
>
> > 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.
>
> You snipped out the relevant part of the RT message. And who brought up
> Windows?
>

I thought we are trying to address the fact that Perl is perceived to be
suboptimal compared to other languages in terms of "per application"
installations.

That implies a cross platform solution, which implies it needs to work with
Windows as well.

Yves

Sent from my iPhone

> On 14 Mar 2023, at 18:56, Oodler 577 <oodler577@sdf-eu.org> wrote:
>
> Ultimately, sounds like you got a client in a pickle and are trying to figure out
> where Perl can help, which is fair. So I am trying to get clarification on what
> you're wanting Perl do to make up for your own clients mess.

I did not get a client into a pickle. They were already in one and I was bitten by it (it never made it close to production). Further, they were in one that many of my clients have faced.

Other languages make this easy to solve. Perl needs to do this too. Bash is not an option.

Best,
Ovid

* Curtis ?Ovid? Poe <curtis.poe@gmail.com> [2023-03-14 19:49:30 +0100]:

>
>
> Sent from my iPhone
>
> > On 14 Mar 2023, at 18:56, Oodler 577 <oodler577@sdf-eu.org> wrote:
> >
> > Ultimately, sounds like you got a client in a pickle and are trying to figure out
> > where Perl can help, which is fair. So I am trying to get clarification on what
> > you're wanting Perl do to make up for your own clients mess.
>
> I did not get a client into a pickle. They were already in one and I was bitten by it (it never made it close to production). Further, they were in one that many of my clients have faced.

Apologies, I don't know why I said it that way. I was not thinking
you got them into the pickle.

>
> Other languages make this easy to solve. Perl needs to do this too. Bash is not an option.
>

I am just looking for a use case. I have some of my own, maybe we should
collect some that stand in the way of doing productive things and
actually making a living off of Perl; and we might be on to something.

Cheers,
Brett

> Best,
> Ovid

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

I may have a solution but it depends on docker, a new project I am working on: https://github.com/PaulGWebster/perlbase?tab=readme-ov-file

The general idea is a docker container with a sane set of default modules and a default user that can be logged in via pubkey only ‘perl’.

For package management, carton is used (for the system level and user level), however by volume mounting ~/perl5 it would be possible to implement a system that allowed you or the owners to drag and drop in what they require.

Just an idea, this is a relatively new project and I am primarily just working on the core features, so would be nice to see if it could suit your needs and if not why ????

* Thank you for your time
* Paul G Webster

> Hi all,
>
> I'm sure this has been discussed before, but I find it hard to search
> effectively with https://www.nntp.perl.org/group/.
>
> 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
> <https://metacpan.org/release/GUGOD/App-perlbrew-0.96/source/META.json> show
> a number of dependencies which might alter our system Perl. I think
> installing from https://perlbrew.pl/ avoids this (it's fatpacked), 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.
>
> 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.
>
> Best,
> Ovid

On Tue, Feb 13, 2024 at 11:08?AM Paul Webster via perl5-porters <
perl5-porters@perl.org> wrote:

> I may have a solution but it depends on docker, a new project I am working
> on: https://github.com/PaulGWebster/perlbase?tab=readme-ov-file
>
> The general idea is a docker container with a sane set of default modules
> and a default user that can be logged in via pubkey only ‘perl’.
>
> For package management, carton is used (for the system level and user
> level), however by volume mounting ~/perl5 it would be possible to
> implement a system that allowed you or the owners to drag and drop in what
> they require.
>
> Just an idea, this is a relatively new project and I am primarily just
> working on the core features, so would be nice to see if it could suit your
> needs and if not why ????
>

Note: For those wanting more context, you can read a summary at
https://www.nntp.perl.org/group/perl.perl5.porters/2023/03/msg265979.html
You can also read the full (long and daunting) thread at
https://www.nntp.perl.org/group/perl.perl5.porters/2023/03/msg265923.html

Paul, your project looks great! For this work, Docker was discussed and for
many projects, it's fine. In fact, for many projects it's amazing. But I
don't think it's what we're looking for here. One of the biggest is that
it's piling on another layer of abstraction which requires developers to
potentially learn Dockerfile syntax, container management, networking
within containers, and volume mapping. This learning curve can be steep for
those not already familiar with containerization. Also, I can't tell you
how many times I've connected to Docker to get something done, only to find
out that my tools don't work because the container doesn't support my
particular development setup. I have a custom debugger setup which, out of
the box, rarely works on Docker, but is amazing (for me) on my machine.

Docker also can impose some significant performance obstacles, depending on
your setup.I have Mac silicon. If images aren't built targeting it, my
system slows to a crawl. I had one test method which took six seconds to
run (far too slow) that jumped up to 1m20s on Docker. It was a nightmare
and made the system unusable until images were built for my architecture.

Further, when Docker ceases to be the new hotness, what then? Or what if
the company in question simply doesn't like Docker? I've definitely
encountered that before.

Having a Perl-based solution means a portable solution. It also means that,
if done well, it could simplify your Docker setup, too.

I'll be honest, if my Docker setup isn't working right, it kills my
productivity because I'm rubbish at solving Docker issues. Debugging why
something went wrong inside of Docker can be painful. If a pure Perl setup
isn't working right, I'm much more productive and I suspect I'm not the
only one.

Best,
Ovid

Thank you for the response!

Completely understandable, I am hedging my bets that docker has reached a large enough size that it will around for a significant time, but who really knows what is around the corner ????

For what its worth reading over the issues you have especially in regard to bootstrapping and what not, bearing in mind they are already tied to system Perl; I think I would try to rely on Carton, it has the least cost of testing and will force a merge of all those possible different versions of libs. Also, its bundle feature would allow you to store ‘the correct libs’ in a single repository.

Reading over your issue also gave me an idea of what to implement next for my perlbase (selectable base Perl version), that is you can pass in an ARGV with the version you want for the system.

I will keep an eye on your thread, be curious to see which path you go and what works!

* Thank you for your time
* Paul G Webster

From: Ovid <curtis.poe@gmail.com>
Sent: Tuesday, February 13, 2024 12:54 PM
To: paul.g.webster@googlemail.com
Cc: perl5-porters@perl.org
Subject: Re: Managing Perl installations

On Tue, Feb 13, 2024 at 11:08?AM Paul Webster via perl5-porters <mailto:perl5-porters@perl.org> wrote:
I may have a solution but it depends on docker, a new project I am working on: https://github.com/PaulGWebster/perlbase?tab=readme-ov-file

The general idea is a docker container with a sane set of default modules and a default user that can be logged in via pubkey only ‘perl’.

For package management, carton is used (for the system level and user level), however by volume mounting ~/perl5 it would be possible to implement a system that allowed you or the owners to drag and drop in what they require.

Just an idea, this is a relatively new project and I am primarily just working on the core features, so would be nice to see if it could suit your needs and if not why ????

Note: For those wanting more context, you can read a summary at https://www.nntp.perl.org/group/perl.perl5.porters/2023/03/msg265979.html You can also read the full (long and daunting) thread at https://www.nntp.perl.org/group/perl.perl5.porters/2023/03/msg265923.html

Paul, your project looks great! For this work, Docker was discussed and for many projects, it's fine. In fact, for many projects it's amazing. But I don't think it's what we're looking for here. One of the biggest is that it's piling on another layer of abstraction which requires developers to potentially learn Dockerfile syntax, container management, networking within containers, and volume mapping. This learning curve can be steep for those not already familiar with containerization. Also, I can't tell you how many times I've connected to Docker to get something done, only to find out that my tools don't work because the container doesn't support my particular development setup. I have a custom debugger setup which, out of the box, rarely works on Docker, but is amazing (for me) on my machine.

Docker also can impose some significant performance obstacles, depending on your setup.I have Mac silicon. If images aren't built targeting it, my system slows to a crawl. I had one test method which took six seconds to run (far too slow) that jumped up to 1m20s on Docker. It was a nightmare and made the system unusable until images were built for my architecture.

Further, when Docker ceases to be the new hotness, what then? Or what if the company in question simply doesn't like Docker? I've definitely encountered that before.

Having a Perl-based solution means a portable solution. It also means that, if done well, it could simplify your Docker setup, too.

I'll be honest, if my Docker setup isn't working right, it kills my productivity because I'm rubbish at solving Docker issues. Debugging why something went wrong inside of Docker can be painful. If a pure Perl setup isn't working right, I'm much more productive and I suspect I'm not the only one.

Best,
Ovid