Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 8, 2023 13:19
Subject:
Re: Managing Perl installations
Message ID:
CANgJU+U4YCONgvsAOf2xwxBa63bZeoPAoejotOeTFo3FRJqfvg@mail.gmail.com
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/"
Thread Previous
|
Thread Next