I have never used the Perlbrew. Should I use it?
It depends; I would want others to chime in on this. I tried Perlbrew recently; it's a lot closer to downloading and compiling Perl from scratch, so it seems intended for the serious or experienced Perl user that likes to have more control over their Perl than afforded by a turnkey distribution or package manager. So I have the impression of it being overkill for end-users, but that being said, it might still be more beginner friendly than I realize, for example if there's good resources out there for guiding beginners. One advantage it would have is consistency across OSes.
For end-users (i.e. non-programmers) or beginners, I think a more turnkey Perl distribution may be preferable, for example ActivePerl. However, if you're tech-savvy enough to be comfortable with using OS package managers like Homebrew, then that option may work fine: just look into how it organizes pre-packaged Perl modules, and how using tools like cpanm to get any modules that aren't prepackaged will work alongside the prepackaged ones. Maybe ask the package manager's community directly instead for installation advice, since many others in the Perl community won't be experts on it.
| [reply] |
I just tried to install the macport again and use "sudo port install 5.26-gd" and no error message upon completion of the installation. However, the same error message "...Image.pm" not found when I ran the perl script. I can find the PD folder and PD.pm Image.pm on the working imac, but not on the macbook. Again, I suspected that the GD is not properly installed. Hahaha... I tried this for 3 days now, and including past multiple attempts in the past couple of years. This was a great perl script written for me and I hate to give it up. Again, thank you for your help.
| [reply] |
Asker has already found a solution as of writing this, but here are some other thoughts I have were this not resolved:
Some reasons that I advocate first trying to install modules through a package manager, if you're using Perl from one:
- All dependencies (including non-Perl ones) will automatically be satisfied.
- For modules containing C code, any peculiarities in compiling for your platform will already be handled.
- If something goes wrong with using the module installed from a package manager, cleanup is easy: use your package manager's uninstall/remove command.
(If you were installing from cpan/cpanm, you would have to gather all non-Perl dependencies, and then specify any platform-specific workarounds yourself. Uninstalling Perl modules with cpanm is possible, but it is an afterthought.)
However package manager modules do have a higher chance of being outdated, since someone has to manually incorporate an update. (Or, as on many Linux distributions, there is a "feature freeze" imposed on packages, meaning that new upstream releases usually have to wait until the next OS release.)
To my knowledge, any modules installed from cpan/cpanm (e.g. path containing "site_perl") will take priority over modules installed using a package manager (path with "vendor_perl"). If a "site_perl" module is not properly installed, or is not completely uninstalled (e.g. empty directories left behind by cpanm --uninstall), your Perl program will fail to load the module in "site_perl" (because it thinks it's there), and not bother trying the module in "vendor_perl" instead; some manual cleanup might be involved if this happens.
| [reply] |
