Support scoped _GO_* variables for plugins #130
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a step towards #120, in which plugin command scripts will now have their own scoped `_GO_ROOTDIR`, `_GO_SCRIPTS_DIR`, `_GO_SEARCH_PATHS`, and `_GO_PLUGINS_PATHS`. This will encourage more composable plugins, some which may even operate as standalone applications that can be incorporated wholesale into other applications. Notice that the search path precedence is: - _GO_INJECT_SEARCH_PATH - _GO_CORE_DIR/libexec - _GO_SCRIPTS_DIR - _GO_SCRIPTS_DIR/plugins/*/bin - any inherited _GO_PLUGINS_PATHS from the parent environment The implication of the last two points is that command scripts installed as plugins will first search for plugins in their own `_GO_SCRIPTS_DIR`, then through the `_GO_PLUGINS_PATHS` inherited from its parent script. These `_GO_PLUGINS_PATHS` search paths effectively build a command path search that recurses up to the top-level `_GO_PLUGINS_DIR`.
Part of #120. Plugin command scripts now have their own scoped `_GO_ROOTDIR`, `_GO_SCRIPTS_DIR`, `_GO_SEARCH_PATHS`, and `_GO_PLUGINS_PATHS`. This will encourage more composable plugins, some which may even operate as standalone applications that can be incorporated wholesale into other applications. This lays the groundwork for: - sharing a single copy of a plugin between all plugins that may depend on it - installing specific versions of a plugin within plugins themselves to resolve version incompatibilities with other installed versions of a plugin - circular dependency support, though such dependencies are strongly discouraged
In the previous commit for PR #130, in order to allow plugins to have their own scoped `_GO_ROOTDIR`, it was necessary to remove its `readonly` constraint. I'd forgotten to update `tests/vars.bats` to remove the `-r` flag in the expected output.
I realized that the previous way `_GO_PLUGINS_PATHS` was getting built would allow nested plugin paths to leak up into the environment of plugins closer to the `_GO_PLUGINS_DIR` root. After considering how to filter `_GO_PLUGINS_PATHS`, I realized the best solution was to build it by walking up the directory tree whenever a plugin is executed. Ironically, this is similar to another commit I'm working on in another branch to find plugin files (specifically plugin modules, though the mechanism is generic) in a similar fashion.
mbland
added a commit
that referenced
this pull request
Jan 26, 2017
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`).
This was referenced Jan 26, 2017
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #120. Plugin command scripts now have their own scoped
_GO_ROOTDIR,_GO_SCRIPTS_DIR,_GO_SEARCH_PATHS, and_GO_PLUGINS_PATHS. This will encourage more composable plugins, some of which may even operate as standalone applications that can be incorporated wholesale into other applications.Notice that the search path precedence is:
_GO_INJECT_SEARCH_PATH_GO_CORE_DIR/libexec_GO_SCRIPTS_DIR_GO_SCRIPTS_DIR/plugins/*/bin_GO_PLUGINS_PATHSfrom the parent environmentThe implication of the last two points is that plugin command scripts will first search for other command scripts in their own
_GO_SCRIPTS_DIR, for plugins in their own_GO_SCRIPTS_DIR/plugins/*/bin, then through the_GO_PLUGINS_PATHSinherited from the parent script. These_GO_PLUGINS_PATHSsearch paths effectively build a command path search that recurses up to the top-level_GO_PLUGINS_DIR.This lays the groundwork for:
A future PR/commit will support a similar mechanism for plugin module (
plugin/lib) imports.