add ZSH_MODULE_PATH to customize module path when zmodload

[j-hao]

This will allow oh-my-zsh still works when modules are moved to other place instead of path from compile time config

[apjanke]

This sounds like a broken zsh installation which should be fixed by just changing $MODULE_PATH instead of adding a hook in Oh My Zsh to do so. Is there a use case for fixing the module path only within OMZ?

[j-hao]

My situation may be not that common. We have zsh built at build machines with some dir generated by rules, deploy to my box and create same symlinks so I can get the latest version of built zsh. Every time I got a new built, check_for_upgrade will fail and complain about not found datetime module since the new zsh has a different install dir setup. This happens even I set module_path to symlink one since zsh will only look for the build time one (-f) and not from this env var when invoke zmodload within script.

After digging around, there is another potential solution:
Given it's not good idea to modify /etc/zshenv, I can update module_path inside my own ~/.zshenv, this requires to remove -f when invoke check_for_upgrade.sh. This seems less disruptive. What do you think about this approach?

PS, from http://zsh.sourceforge.net/Guide/zshguide02.html
if you start the shell as `zsh -f', the option becomes set, so only /etc/zshenv is run and the others are skipped.

[apjanke]

This really sounds like your build system is producing broken zsh installations. You should see if you can fix your build & deploy process so the zsh/* modules can work without additional configuration.

If you must customize $MODULE_PATH at run time, then /etc/zshenv or ~/.zshenv seem like the right place to do it. Be careful: these files are shared by all zsh installations by default, so you'll need your logic to choose the right $MODULE_PATH for the particular zsh build that is running it. And it should probably be /etc/zshenv, because otherwise your zsh -f will be broken. Regardless of OMZ's behavior, some built-in zsh commands have internal dependencies on modules, and will break if they can't load them.

$ module_path=/some/bogus/path
$ limit
zsh: failed to load module `zsh/rlimits': dlopen(/some/bogus/path/zsh/rlimits.so, 9): image not found

As far as removing the -f from the zsh -f check_for_upgrade.sh call, I'm going to defer to the core maintainers. I don't know that we trust users to not have a ~/.zshenv that could break things (OMZ tries to support zsh beginners as much as it can), so for launching maintenance scripts, we might want to stick with -f.

[j-hao]

Thanks for your opinion. I agree that the original pull request is not a good solution. I do think remove -f is reasonable which will give user ability to customize certain things. If remove -f is too risky, we can add a flag to allow users to toggle this behavior. By default, OMZ will continue use -f and with flag on, it will run without -f. Does this approach make sense to you?

[apjanke]

I think I understand where you're coming from. But, no offense, I think that's a bad idea. Introducing that low-level variability complicates the OMZ scripts. As far as I can tell from the Zsh documentation and mailing lists, the baseline of a working zsh installation includes the bundled zsh/* modules, and that's what the current OMZ code assumes. I think that for scripts, it would be better to reduce the per-user variability, and make -f the default in more places.

Doing this change also implies that your setup is an "okay" or supported zsh deployment, which I don't think it should be. I think that instead of changing OMZ to support this unusual build scenario, I think that whatever community effort there is to expend here would be better spent on helping your organization fix their Zsh build & deploy process, and encouraging other organizations to not make similar mistakes. I'd be happy to spend time discussing your build & deploy system, but I think pushing support for this setup to the general OMZ community would not be in the best interest of the great majority of users.

[j-hao]

Got it. Thanks for your time. I know my use case is not that common and I'll see if I can change on our side

[apjanke]

Cool. Feel free to ping me if you'd like to discuss your build process. I've done versioned zsh builds before (mostly on OS X) and may be able to assist.