http://qs321.pair.com?node_id=455431


in reply to Re: package splitting and 'our' use
in thread package splitting and 'our' use

This approach forces the preliminary "bootstrap" configuration package to include modules that depend on it. Suppose, for example, that part of the configuration set up is to use different package @INC paths to pull in different code trees based on environment (development versus production, etc.). Having to use the packages the configuration is trying to affect means that they may get pulled in too soon, rendering the configuration piece useless for those packages. It's your classic chicken/egg problem. My goal is to write these configuration pieces so they're as independent of the rest of the code as possible, thereby allowing them to set things up that affect the rest of the run-time environment without having to hook into those run-time packages too deeply. They're very much like shell level environment settings in that regard.