Front page | perl.perl5.porters |
Postings from March 2023
Re: Managing Perl installations - summary
Thread Next
From:
Joel Roth
Date:
March 11, 2023 05:10
Subject:
Re: Managing Perl installations - summary
Message ID:
20230311051003.nmjff3re47g67uql@sprite
Hi,
I pulled together an unofficial summary from Ovid's and
demerphq's posts. Mail extracts follow the bullet points
below.
* Developing and deploying programs is different than for libraries
* The perl community has done a good job for libraries
* Want better support for working with multiple perl versions and lib directories
* A native, local perl approach is preferable. For example, docker has
some drawbacks and we don't want to be bound to it.
* Could be part of core perl and serve most needs
* Will make it easier to bring new perl developers up to speed
* Should be as good or better than the toolchains of other dynamic languages
* Consider prior art: CPAN, npm, left pad
* OODA (observe, orient, decide, act)
* Applications need a mechanism to guarantee their dependencies,
to ensure they do what they intend.
* The app's perl should be sufficiently independent of system perl and
the environment with restricted functionality, for example, omitting
utilities such as perlbug (section IV, below).
* Some clients need to blacklist particular modules--ensure
they're not installed as part of another module's dependencies.
* Could be implemented through a cpanfile with options to:
- require a particular library version or digest or authoritative source
- prohibit installing certain modules as part of a
dependency chain (sections V, VI)
Mail extracts
Ovid:
I.
1. As a[n] [ed: application] 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
demerphq:
II.
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.
III.
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.
IV.
1. In an application perl most of the environment variables understood
by perl should *not* randomly come from the environment. They should
probably come from a specific configuration file which is private to
and owned by the application only.
2. In an application perl none of the libraries should come "from the
perl" they should come from the application itself. There should be
no "site_perl" directory, nor "lib" directory built in. CPAN should
never install modules into the perls trees, and should not even be
usable with it. (Modulo maybe modules required to implement internal
features of that perl, for instance the NamedCapture ties that we used
to have implemented as perl modules)
3. There should be no perlbug or other utilities installed with the
perl except those that come with the application.
4. All features where a perl knows to execute another perl should be
disabled. If an application is intended to be run against a specific
perl executable that perl executable shouldnt be tricked into spawning
another perl.
5. Features like taint, and whatnot should be compiled out, or in,
depending on the applications needs.
This isnt an exhaustive list btw, just trying to think this through.
Ovid:
V.
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.
VI.
I've had various clients forbid certain modules. Some modules may not be
used directly in client code, and some must not be even used indirectly
because the author's done something really naughty. You pull in Mega::Module
which loads half of the CPAN and don't notice you have the naughty module,
well, now it will be easier in a central place to drop in:
# syntax is bad, but shows the concept
forbids 'Naughty::Module';
forbids 'Other::Module' => [ '<' => v1.2.3 ];
forbids 'Buggy::Version' => [ '1.4..1.7', '2.3' ];
VII.
Martijn > My employer uses Docker for this and it has been the best
> [thing] they ever did for Perl (and other) projects. Makes
> lots of problems just disapear.
Yup. Docker is amazing, but not everyone wants to use
Docker. I'm on a Mac and using Docker on a Mac is painful.
When clients provide me with Docker, it makes life easy, but
the code runs like cold molasses (you can hit your favorite
search engines for tons of ways to try to fix this and tear
your hair out in the process).
By having a native, local Perl solution, we can provide a
solution that other languages provide and the core solution
would probably serve most needs. When, and if, someone needs
more, they'd hopefully have more experience in understanding
their needs and finding a better solution.
-end-
--
Joel Roth
Thread Next
-
Re: Managing Perl installations - summary
by Joel Roth