Part of #120. This implements semantics similar to npm's node_modules by providing a parent directory-recursive plugin search.
After implementing #130 and coming back to my original @go.find_plugin_item_path that I'd had in another branch, I realized the parent-recursive search could be abstracted into @go.search_plugins. Ironically, it was implementing the algorithm first in _@go.set_search_paths than enabled me to more thoroughly test the extracted function, since plugin scope was already established and tested. Talk about circular dependencies!
As with the earlier commits building up #120, the implication is that rather than having all plugins comprising an application always checkout their own plugins in their own subtree, eventually they can be installed in their parent's plugin directory. This nesting of plugins can be arbitrarily deep, ending at the top-level _GO_PLUGINS_DIR.
This will help break cyclical dependencies (though they should still be avoided) and save disk space, and paves the way for semantic versioning and npm-like functionality (but in pure Bash, modulo git or curl, et. al, via ./go get).
Coverage increased (+0.05%) to 95.11% when pulling 7cbb2395531b5adc2fb31f73265531a92d730000 on search-plugins into 60f2ec603de63a7b4a0216fc80db4652930cd56d on master.
Part of #120. This implements semantics similar to npm's
node_modules
by providing a parent directory-recursive plugin search.After implementing #130 and coming back to my original
@go.find_plugin_item_path
that I'd had in another branch, I realized the parent-recursive search could be abstracted into@go.search_plugins
. Ironically, it was implementing the algorithm first in_@go.set_search_paths
than enabled me to more thoroughly test the extracted function, since plugin scope was already established and tested. Talk about circular dependencies!As with the earlier commits building up #120, the implication is that rather than having all plugins comprising an application always checkout their own plugins in their own subtree, eventually they can be installed in their parent's plugin directory. This nesting of plugins can be arbitrarily deep, ending at the top-level
_GO_PLUGINS_DIR
.This will help break cyclical dependencies (though they should still be avoided) and save disk space, and paves the way for semantic versioning and
npm
-like functionality (but in pure Bash, modulogit
orcurl
, et. al, via./go get
).