Closed DavidMarchant closed 5 years ago
Rebased on https://github.com/alces-software/adminware/pull/158 for the recursion code
So this resolves the first part of the problem: We are no longer saying we are passing the context but not. However it now makes it impossible for the context to be passed into the commands
module through Config.commands
.
So the next step is to obey what commands.run
says in the hash (regardless what is going on in Config/command_generation).
Do you want to context to be passable to a) just runner
b) all functions decorated with Config.command
or c) all functions decorated with something that uses command_generation
?
Also should i possibly put this in a separate PR as it's new functionality?
Keep it in the same PR as the main purpose of the refactoring is to allow this functionality.
The context should be passed to the calling object (e.g. runner
) IFF the calling object explicitly defines pass_context
in its group/command hash.
~In
parse_group_command_config
in command generation~ Minimise presence of unrelated code inrun
commandFixes #161
Edit 12/11/18: Now all
ConfigCallback.run
s require ctx as their last param CombinedConfigCallback.run
's 2 types of action away from using whether ctx has been passed within logic NB! as a direct consequence of the above - if a namespace has it's ownconfig.yaml
this will also be executed along with any subcommands and subnamespacesrebased on #158 for recursion code
Edit 13/11/18: Now additionally moves all code for creating dicts for command generation into new module
command_dict_creator
This involved some manipulation of other modules inc. theconfig
module's const definitions Alsoctx
is now always passed fromConfigCallback.run
(as per IRL)Also fixes #152