Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations
Thread Previous
|
Thread Next
From:
demerphq
Date:
March 8, 2023 10:56
Subject:
Re: Managing Perl installations
Message ID:
CANgJU+X2anqP0My3aHHJOVcqWbZ8_bMXf4Otunn7p6WcUtpuDw@mail.gmail.com
On Wed, 8 Mar 2023 at 08:41, Ovid <curtis.poe@gmail.com> wrote:
>
> On Tue, Mar 7, 2023 at 8:14â¯PM Joel Roth <joelz@pobox.com> wrote:
>>
>> > With that bit of hand-waving, I have a local, per-client Perl, configured
>> > how the client needs it, and automatically pointing to local (per
>> > directory) CPAN installations. This allows me to create an isolated setup
>> > that doesn't risk interfering with another Perl installation or its modules.
>>
>> plenv might need enhanced if you want to specify the
>> local::lib for a particular directory. We previously got
>> this behavior by letting perl load libraries from the
>> current directory.
>>
>> 1. https://github.com/miyagawa/plenv-contrib
>
>
> Thanks for that, Joel.
>
> So I think the overall idea is better explained now. There's plenty of CPAN evidence that this is both feasible and desirable. As the default situations stands now, we have this from the node.js blog:
>
>> CPAN and RubyGems have blurred the lines between development tools and system package managers. With npm we wish to draw a clear line: it is not a system package manager. It is not for installing firefox or ffmpeg or OpenSSL; it is for rapidly downloading, building, and setting up Node packages. npm is a development tool. When a program written in Node becomes sufficiently mature it should be distributed as a tarball, .deb, .rpm, or other package system. It should not be distributed to end users with npm.
>
>
> I believe the above paragraph is correct and sums up what I would love to see addressed. Getting a similar development tool in the Perl code.
Id put it the exact opposite than you have. I think Perl has a very
strong tradition and bias towards treating all software as libraries
(which i think is that they mean by "development tool"), so I think
what we do well is the development tooling part. 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. To the point where we
often bundle applications /as/ libraries, and then try to shoehorn
them together into the same management tooling and space. Our support
for programs and applications is pretty poor. We could definitely do
better there. But note that is the opposite of what you said, and is
actually more aligned with the paragraph you quote. I think that
paragraph is right that we do tend to blur the line between some of
the things they mention. We treat applications as libraries that are
configured, instead of programs that are supported by specific
libraries. A subtle but key distinction.
> So getting back to the original question that I fumbled so badly :), is this something P5P would be willing to see in the Perl core? If so, while I wasn't intending this to be a pre-PPC, should one follow, or should a PPC be written?
It still isn't really clear to me that core needs to be involved here.
Maybe it can be and maybe it should be, but I am not clear on what and
where. We simply dont think about programs very much, we are so
strongly biased towards all the world being a library that we tend to
convert our programs into libraries so they can fit into that space.
What we need to do to support *programs* in core isn't clear to me at
all. I definitely would like to see the Perl community as a whole
think about programs as distinct from libraries, but it isn't clear to
me if that means achieving consensus on what differs between a program
and a library, or if it means actual code changes to core. If it does
mean changes to core I am interested using my skills to help solve the
problem. but I think this subject needs a lot more gestation before we
get to that point.
We should do some brain-storming on this what do we think is different
between "program think" and "library 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.
This goes against our model of a unified library tree. If we thought
more "program" like we would not have a standard library tree which
everything gets installed into, we would have a per application
library tree, and we would make it easier for a perl program to
control its libraries. This means that we probably should not support
as many varieties of layout of libraries. Eg versioned library trees,
etc. We should probably ditch some of the build modes we support and
only support the simple per perl library tree. This has been the
tendency of the community for some time, but we still have vestigal
support for using the same library with multiple perls, and we still
have the vestigal concept that library trees are not relocatable, etc
(although we have support for relocatable lib, its opt-in).
If there are K programs on someones box that are built out of Perl
should there be K perl binaries used? From a program-think perspective
probably yes, although maybe it would make sense to have a way to
share the perl binary across multiple apps that are intended to target
that version of perl. That means we should ditch or extend the idea of
a "standard location" for the perl binary, and we should probably move
away from the notion that you just stick perl/bin into your path and
let all your scripts run against the standard perl. It would also
eliminate all the issues with "system perl" versus "customized perl".
So if we are going to change this we probably need to really rethink
how things like Configure work in terms of these build options.
IMO there is a lot to think about before we actually understand what
needs to change in core. But I do think this is something worth doing.
The fact we have perlbrew, plenv, local::lib, and so much other
support along these lines suggests we are doing something wrong. I
think the first step is to realize realize that our success in
managing *libraries* has not translated into success managing
applications, and in fact that our strong library bias has played
against us in the long run. That is a sentiment I definitely agree
with. If we can start with the premise that we do programs wrong, then
we can start reasoning about how to do them right.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next