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

[René J.V. Bertin]

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.