Add parent-recursive plugin module search #136
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
Done during the course of adding new test cases in later commits.
Part of #120, built upon `@go.search_plugins`. This implements semantics similar to npm's `node_modules` for library modules. Since Bash's flat namespace creates the potential for function redefinitions, a warning is emitted when a module collision occurs. The hope is that this will encourage good compatibility practices via semantic versioning, ultimately reducing the need for nested plugin module checkouts due to version incompatibilities. Since command scripts should define their own functions using a project-specific namespace that prevents them from being treated as exported units when sourced by a parent script (especially those exported as plugins), command script namespace collisions should be less of a concern. Also, the `_@go.set_use_caller` wrapper function is necessary due to the same Bash <4.3 bug from commit 2b8f09f. Accessing `BASH_SOURCE` and `FUNCNAME` through at least two levels of indirection apparently resolves the issue; this is why `@go.print_stack_trace` always worked. Confirmed the breakage from the previous commit under Bash 3.2.57 and 4.2.25 is resolved by the `_@go.set_use_caller` wrapper.
The test that first caught this was `modules/main: --imported`. Added the new `modules/use: import builtin module` test case to cover any regression in a more obvious way.
Realized that if a plugin contains an internal or exported module that matches the same filename as an internal or exported module in the parent, that the code as it was would find the parent module first. The fix was straightforward: extract most operations into `_@go.find_module`. Touching up the "modules/use: prevent self, circular, and multiple importing" test case required a bit more care to touch-up, since the plugin module in the test could no longer access its parent's modules any longer.
This was referenced Jan 27, 2017
Closed
mbland
added a commit
that referenced
this pull request
Jan 31, 2017
This concludes the refactoring of `_GO_USE_MODULES` to provide correct `@go` command script scope for plugin modules. It is germane to #120. Whereas #136 implemented correctly-scoped lookup of other plugin modules, this allows any module, plugin or otherwise, to invoke its own command scripts or plugin command scripts via `@go`.
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, built upon
@go.search_plugins. This implements semantics similar to npm'snode_modulesfor library modules.Since Bash's flat namespace creates the potential for function redefinitions, a warning is emitted when a module collision occurs. The hope is that this will encourage good compatibility practices via semantic versioning, ultimately reducing the need for nested plugin module checkouts due to version incompatibilities.
Since command scripts should define their own functions using a project-specific namespace that prevents them from being treated as exported units when sourced by a parent script (especially those exported as plugins), command script namespace collisions should be less of a concern.
Also includes some touch-ups to other test files along the way.