My only beef with the port system, which is not particular to macports, but to any packaging manager, is how you manage the multiple libraries of available modules. If you use port, you should probably use it for common modules too (and there are many, like p5-www-mechanize).

If it's not on the macports list (and there are many), then it feels ugly to try to use CPAN to manage a second packaging layer on top of that, and not know whether the module you're requesting will end up building a constellation of modules that are unproven on your platform.

The last alternative is to go through the dependency hell yourself in your own local PERLLIB directory, which is only slightly more unsavory and has the same pitfalls.

When I did more development on Red Hat Linux, the same deal applied to their repository, but I got familiar with how to repackage most CPAN modules with cpanflute at the time, so I could at least work with one installation library path. With macports, I'm not familiar with this route: how to make a port file for a CPAN module, so it would install safely in the same tree with other port-installed p5-* modules.