Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations
Thread Previous
|
Thread Next
From:
Ovid
Date:
March 8, 2023 12:29
Subject:
Re: Managing Perl installations
Message ID:
CA+M4CHvL7c+x5k7hi9DUxs3asyEBw+1LQHMD3eZ83YCAFhh4yQ@mail.gmail.com
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
Thread Previous
|
Thread Next