Idiomatic process for handling needed external language modules for which there is no port

[Daniel J. Luke]

On Dec 15, 2023, at 11:57 PM, Kenneth Wolcott <kennethwolcott at gmail.com> wrote:
>  Scenario A:
> 
> 1.  Install Perl from MacPorts.
> 2. Need Perl module XYZ.
> 3. Perl module XYZ does not exist on MaqcPorts.
> 4. Install (using CPAN, CPANm, or manually) the XYX module locating it
> under the MacPorts port.
> 5. MacPorts complains about things installed under /opt/local that it
> didn't put there (makes sense).

Do you have specifics here?

MacPorts installs perl modules into the vendor_perl directory, if you install manually it should default to the site_perl directory. You can examine @INC to see where perl will look for modules (and even adjust it if you want - https://perldoc.perl.org/perlvar#@INC )

% /opt/local/bin/perl -e 'print join("\n", @INC)."\n";'
/opt/local/lib/perl5/site_perl/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.34
/opt/local/lib/perl5/vendor_perl/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.34
/opt/local/lib/perl5/5.34/darwin-thread-multi-2level
/opt/local/lib/perl5/5.34

You can have conflicts for modules that install things into $prefix/bin, or similar, though. Using local::lib (https://metacpan.org/pod/local::lib) is a nice way of handling things if you want to be sure not to conflict with a perl install (or have different projects that each need conflicting sets of libraries). It's pretty rare in the perl world for there to be a situation where you'd need module version A for one project and module version B for another project (most modules do a good job of backwards compatibility). 

> Scenario B:
> 1.  Install Perl from MacPorts.
> 2. Perl script I want to use requires a more recent version of Perl
> than those found on MacPorts.
> 3. Install my own version of Perl (usually from source).
> 4. Need Perl module XYZ.
> 5. Install Perl module XYZ (trying to match it with my own install
> location, but frequently screw this up).
> 6. End up with weird path issues, Perl and/or module(s) all confused.

I don't think anything can make it so you don't have to understand which perl install and which modules you are using.

> Scenario C:
> 1.  Install Perl from MacPorts.
> 2. Install Perl from perlbrew.
> 3. Run into problems with #3-6 from Scenario B.

This is how I normally handle things - let Macports' perl be just for things in MacPorts that need perl and otherwise pretend it isn't there. Use perlbrew to select the perl install that I want to use, setup my shell to use perlbrew (so typing 'perl' gets my my perlbrew perl) and set an appropriate #! in my scripts to use that same perl. [I actually create a perlbrew alias that I put in my scripts so that I can re-point it to a newer perl if/when I upgrade]

> Scenario D:
> 1 Use a Docker container for Perl exclusively for these experiments
> that I'm trying to use Perl for (various math learning, etc);
> 2. Install Perl from source
> 3. Install all needed external Perl modules myself on the Docker container.
> 
> Looks like I end up using Scenario D for Perl and Raku.  Now
> considering this for Julia, Python, Rust, etc

containers for everything is the modern way of solving this problem. I mostly hate it (it's the new static-linking) but it can be pretty convenient

-- 
Daniel J. Luke