Idiomatic process for handling needed external language modules for which there is no port
Hi; I'm trying to understand how to logically handle external modules for a language under MacPorts. TL;DR: How do you do package management on MacPorts for languages which might need modules which MacPorts doesn't have? This problem exists for many languages supported by MacPorts; ie: Perl, Python, Raku, Julia, etc 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). 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. Scenario C: 1. Install Perl from MacPorts. 2. Install Perl from perlbrew. 3. Run into problems with #3-6 from Scenario B. 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 So one of my problems is that I do not have a foolproof method (understanding) of how to install modules (Perl, Raku, etc) so that the modules are not in conflict with multiple installations of the main language. Bottom-line question: How do you do package management on MacPorts for languages which might need modules which MacPorts doesn't have? Thanks, Ken Wolcott
