On Wed, 8 Mar 2023 at 14:19, demerphq <demerphq@gmail.com> wrote: > > If we look at it from the standpoint of my user story, I think core should be involved because I want to download and install Perl and already have the primary tool necessary to implement that story. > > 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. I was trying to think about "what would be different for an application perl and a site-wide perl", and here is what i came up with: 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. yvesThread Previous | Thread Next