* The FlowGroup class was created to represent the group concept and store
the necessary variables and methods.
* The classmethod make_group was created which returns a decorator that
adds a _flow_group label to functions for later registration. In
addtion, make_group also adds an entry to the new _GROUPS attribute in
the _FlowProject class.
* A function _register_groups was added that registers groups by using
the _GROUPS and _OPERATIONS attributes of the current and parent
classes.
* The __init__ method of FlowGroup was changed to automatically register
groups and add operations at initialization.

Adds the group commandline argument to submit, run, and script.

* _main_submit modified to have group path
* submit_group function added to submit groups
* changes do not directly update status
* no checks on if directives work have been made

* changed the way that operation names are gathered for run condition to
aggregate those chosen from -o and -g options.

* Raise ValueError if -o/--operation and -g/--group are set together
* Add logic to include JobGroups as script operations if -o/--operations
is set.

* Adding an options parameter for groups that appends options to the
output of FlowGroup's __call__ method. This allows for you to set
options like --num-passes for a group. These options only currently
apply during submit and script operations.

* FlowGroups now have a complete and eligible method
* FlowGroups now have two cmd's run_cmd and exec_cmd
* FlowGroups.__call__ now takes a flag on cmd mode
* make_group FlowProject method takes correct args and stores them in
  operation function dict correctly
* FlowGroups store operations as a dict now
* _register_groups FlowProject method correctly registers operations
* Temporary changes made to JobGroup to test FlowGroup function

* JobGroups now correctly create unique id.
* JobOperations are removed as they are redundant.
* All _main_script and _main_submit always use group pathway now.
* Exec_mode runs and raises error for groups with more than one job.
* Bundling works with groups of all kinds.

* Changed functions that gather operations.
* Changed the structure of JobOperations
* Add method to FlowGroup to create JobOperations.

* Submit, run , and script all handle groups and operations through -o
* FlowGroups are always created with knowledge of path now this is
required because there is not an easy way to find where an object is
instantiated. The current method uses the stack when using the
classmethod make_group, and the class attribute _OPERATION_FUNCTIONS
when creating FlowGroups directly from a FlowOperation.
* Appropriate errors are raised when undefined behavior might occur.

* Changing FlowGroups compatible method
* Moving submit and JobOperation back to original location
* Added a groups property to FlowProject class
* Moved all call logic for FlowGroup to __call__ method
* Moved exec_mode command-line argument conversion to string to _main
functions.
* Changed logic in _verify_group_compatibility using python's set type
* renamed submit_operations group argument to operations

* Also doing linting changes that flake8 requested.
* The changes to the `_setup_template_environment` were required to
commit with the flake8 commit hook.

* Also adding exec mode to relevant tests.

* Since operations are always expanded from groups before-hand, exec
mode is the correct mode to be in when calling a run command.

* Changing the `get_id` function in `FlowGroup` class to match previous
id in the case of single operation groups.
* Changing `_dumps_op` and `_loads_op` functions to include
`JobOperation` id since it is now an attribute.
* Created a function `_gather_FlowGroups` that takes a list of
group/operation names and returns a list of instances of `FlowGroups`
with removed duplication and error checking.
* Add argument `mode` to submit function. Previously a kwarg check was
preformed. This changes behavior to use the string which is the behavior
elsewhere.
	* _main_submit was changed to pass the string to submit as well.

* All references to `JobOperation.get_id()` are changed to use the
attribute `id`.
* Calls to `script` and `submit` that check output have 'exec' mode
explicitly set.

* Including inheritance hierarchy in gathering operation functions.

* had to refactor operation selection to include fullmatch.

* Also adding necessary tests for group behavior in submit, run, and
script
* Added `operation_ids` as attribute of JobOperation to hold individual
operation ids for resubmitting checks.
* Added `eligible_for_submission` method for JobOperaiton to check if
all operation are not currently submitted.

* For dynamic tests a workflow with multiple steps is tested. For the
groups test, it is more important to show that resubmission is not
possible. The multistep workflow is shown to work in the previous tests.

This is necessary since one assertIn command cannot be used to ensure
all operations are in the command as the ordering in python version 3.5
is not commensurate with python > 3.5.

* Currently the singleton groups must have the same name as the
operation name. As this is not changable by the user that should be
okay.
* I had to set the directives 'executable' and 'override_path' for
singleton groups with the `@cmd` decorator. This results in some ugly
logic that should work, but if there is an easier way should change.

* Removed group status from `set_status` command.
* Redefined `JobOperation.get_status` to always return a list of
  operation statuses.
* Logic has yet to be moved to `FlowProject`. I did not see a clear way
  to query whether a particular job-operation pair was currently submitted
  other than directly searching the project.
* The test change was just to correct for the fact that now `get_status`
  returns a list.

* Also show operation status through querying group status and expanding
  to composing operations.

* Prevents unnecessary checking if the same group is previously submitted

* One path for submission
* One path for running

There is actually no need to further specify what the id *should* look
like. It must be unique, that is the only requirement.

1. Raise error at the point of assumption.
2. Use dedicated exception class to propagate error.
3. Raise SubmitError only during submission.
4. Raise ScriptError during script generation.

  * Simplified logic.
  * Use the group name as argument to -o in all cases.

* may need to change again but fixed a bug on my computer.

* New pathfinding method solves some problems but doesn't resolve all of
  them. Namely, for our tests the 'path' is always the test file.

* Remove six.PY2 testing
* Fix rebase errors
* Remove old function to find operation path

* Test work again with minor refactoring to account for this new API.

Co-Authored-By: Carl Simon Adorf <csadorf@umich.edu>

* Rebasing missed this

Involved FlowGroups respecting ignore conditions

Matches set API better

Now at the time of group functor name conflict is checked.

Templates still broken.

prevents users from having a group named the same as an operation since
singleton groups with operation name are automatically defined, and
shadowing should not be allowed.

No longer recompute the operation list from `_collect_operations`
Also remove ExecCommandError

will currently break with bundling.

Co-Authored-By: Bradley Dice <bdice@bradleydice.com>

Has two decoraters ``__call__`` and ``with_directives``.

Also merge from master

Remove directives from _submit_cmd

Reduce noise in submission directives when 'ngpu', 'nranks',
or 'omp_num_threads' is set to 0