Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations
Thread Previous
|
Thread Next
From:
Ovid
Date:
March 8, 2023 14:18
Subject:
Re: Managing Perl installations
Message ID:
CA+M4CHsAyw0oDy8XJPu3iyCFGHArFeGFo3JE=h-td9MWD6F3SA@mail.gmail.com
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
Thread Previous
|
Thread Next