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