|
|
|
| Perl-Sensitive Sunglasses | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
I have a fairly large codebase which needs to be deployed in a variety of situations/environments. Given the nature of the code, it can have an excessive number of module requirements to cover all the scenarios it can be leveraged for. Instead of doing some type of preinspection of the available modules and then reconfiguring the codebase on the fly or trying to download modules from CPAN, I wanted to wait until runtime and let user configurable data drive what modules should be loaded.
While you can do what you're trying to do, that way will generally lead to insanity. It is much much saner to manage dependencies at the time the dependency is now needed. This generally comes down to two places:
In the case of the second, I would have both a config file and a UI. If the user directly edits the config file, they are responsible for the dependencies (superuser mode). If the UI is used, then whatever code backs the UI should make sure the dependency is met, either by alerting the user to tell the sysadmin or (preferable) installing the dependency itself. Before you say "But you need root!", I say you don't. Check out Perl::Install for an easy way to install Perl anywhere you want. This is what I do when I have an application - it literally has its own Perl installation along with its own modules. That way, I know exactly what user permissions are required to update the install. Before you complain about space, remember that disk space is much much cheaper than people time. My criteria for good software:
In reply to Re: Interesting behavior in eval block
by dragonchild
|
|