Any alternative strategies to limit the proliferation of perl and python packages?

[raf]

On Mon, Aug 26, 2024 at 01:19:32PM +0200, "René J.V. Bertin" <rjvbertin at gmail.com> wrote:

> Hi,
> 
> This is one of those periods where I notice that "damn, I should
> update my Perl5 and/or Python interpreters, but then I'll also have to
> reinstall a whole bunch of modules for them and figure out which old
> ones I can throw out". MAYBE that would be easier if I kept my entire
> installation perfectly up to date, but I have my doubts.
> 
> I just did some quick testing with Python3 and as I thought it's
> possible to *append* the site-packages directories of older 3.x
> versions to the sys.path and get access to anything already installed
> there. Perl is alienware for me but I would be surprised if it didn't
> support a similar trick. IIRC both allow to define the default search
> path via a configuration file, and python at least doesn't complain
> about non-existing directories on that path.
> 
> Wouldn't that at least allow for a non-invasive design (= that doesn't
> break everything) to relax the Perl/Python upgrade requirements for
> ports that have build dependencies on one or both of those, and maybe
> even those that do not install their own binary P/P extensions (= any
> runtime dependencies go through the standalone interpreter)? It'd be
> great if those ports could just depend on port:perl5/port:python3 (the
> latter doesn't but could exist?!) and p5-foo/py-foo ports, and be
> happy with whatever is currently present. That aspect already works
> with perl5 (but I haven't tested it by making a newer perl version use
> packages/pods installed for a previous version).
> 
> R.

I assume that you're referring to perl modules that were installed "manually"
via CPAN rather than via macports. They need to be reinstalled for new versions
of perl. I think the usual solution to this is to install them into a directory
that isn't perl-version-specific.

For example, if perl -V shows this:

  @INC:
    /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

They are all perl version specific, so you could add another directory
to PERL5LIB:

  PERL5LIB=/usr/local/lib/site_perl

Then cpan modules could be installed into /usr/local/lib/site_perl.
Then they would remain available across perl upgrades.

I'm not sure how to make that happen. It presumably depends on which CPAN
client you use. According to https://stackoverflow.com/questions/51880115/install-with-cpan-perl-modules-to-specific-directory-when-several-appear-in-us
here are the cpan commands to make it happen.

  o conf makepl_arg 'PREFIX=/usr/local/lib/site_perl INSTALLMAN3DIR=/usr/local/lib/site_perl/man/man3'
  o conf mbuild_arg '--install_base /usr/local/lib/site_perl'
  o conf mbuild_install_arg '--install_base /usr/local/lib/site_perl'
  o conf mbuildpl_arg '--install-base /usr/local/lib/site_perl'
  [o conf commit]

However, I don't think it would help for modules that require compiling C. I
have a site that requires some CPAN cryptography modules, and just using the
same files isn't enough. They had to be recompiled to match the new perl
version. But it should be mostly fine for pure perl modules.

For python, using virtual environments are recommended, which would address
this, and hopefully they've found a way by now for them to not make it
difficult to run a python program from the command line.

Another option is to create and submit Portfiles for all of the modules that
you use. Then macports should take care of everything. :-)

cheers,
raf