Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations - summary
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 11, 2023 17:35
Subject:
Re: Managing Perl installations - summary
Message ID:
CANgJU+W4CtPxp+FzLgrR3c1cV_1OYc1HUuECxX=hh6gHh09K6Q@mail.gmail.com
On Sat, 11 Mar 2023 at 17:52, Ovid <curtis.poe@gmail.com> wrote:
> On Sat, Mar 11, 2023 at 11:39â¯AM demerphq <demerphq@gmail.com> wrote:
>
>>
>>> Honestly let's leave [publishing to the CPAN] out of this thread Ovid,
>> at least for as long as possible.
>>
>
> Deal.
>
> Also, I *think* the following was understood from our previous
> conversation, but if not, I wanted to be explicit.
>
> In addition to what we've described above, we'll need different "kinds" of
> Perl to compile: local and shared.
>
> If I cd into an application directory, I should be able to pick up the
> local Perl compiled just for that project.
>
> However, I might have multiple projects for the same customer, all running
> on different boxes and having different sets of Perl modules installed, but
> using an identically-compiled version of Perl. Thus, I'd want a "shared"
> Perl, too. I don't need (or want!) to recompile that Perl for every
> application for the same customer.
>
> As a developer, I would also be a customer (the default customer) and
> might like to have that "shared Perl" just for me. I don't want to
> recompile Perl just because I want to create a new module for the CPAN.
>
I definitely appreciate that this would be nice to have. But I do classify
it as "nice to have", eg, if our objective is to make it easy to have
completely independent perls, then its a bit awkward if you add "except
where it is inconvenient". :-)
I think we need to support both style for historical reasons, but lets
focus on doing independent installs first, then think about how we can
share perl binaries between independent projects where it is helpful.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next