On Dec 15, 2023, at 11:57 PM, Kenneth Wolcott <kennethwolc...@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
