Hi Andrew, Thanks for your answer.
On Wed, 21 Nov 2018, Andrew Hewus Fresh wrote: > I fear that this would encourage folks to install and update more > modules from the CPAN that would then conflict with what the ports tree > does. If we had a setup where ports installed into a vendor directory > and CPAN modules installed someplace else I might consider it so at > least it wouldn't easily break pkg_delete, but I would still worry that > someone would update a port and break something and not be able to > easily recover. cpanm does not do anything the included cpan can not do, is just a little bit more convenient and easy to use, so the problem you mention is already there. > I use plenv for testing things and I have heard perlbrew works well too > and both of those install into a local perl instead of into the same > place that ports put modules. That of course doesn't actually fix that > if you use system perl these tools will let you break things, but the > manual install here hopefully means that you know enough to fix it when > you shoot your foot. I use plenv too for tests. It's really convenient and has the possibility of setting up perl versions globally, per folder or per shell. But sometimes one does not need all of that, building it's own perl and all. For instance I've used it a lot (a part from testing), to get modules not present in packages/ports to a remote server or low resources machine. Installing to a specific folder and then modifying @INC like so: cpanm -l ./perl5 -L ./perl5 Foo::Bar perl -I./perl5 foo.pl (or even inside the script with use lib;) But I get this is a niche use case probably and does not justify a port. Cheers, -- Paco Esteban https://onna.be/gpgkey.asc
