v2 Part 1: Refactor nightmarish parsing configuration to be DRY and elegant

[svanoort]

The way parsing is handled for the core tests is a nightmare and seriously impedes the ability to extend pyresttest. We have a special case for each parse option, and the handling of command-line, test-level, and testset options is completely bonkers, since has separate parsing code.

Let's apply lessons learnt to fix this. Instead of the long, brutish mess of parsing (and test of the parsing), let's apply the lessons learned in the validator classes, and apply a registry + dynamic parse function method. But, let's do it better since type coercion is required.

Use registries:

RESERVED_KEYWORDS = set('test', 'blah', 'bleh')  # Cannot be used as a macro name
MACROS = {test: parse_test, benchmark: parse_benchmark}  # Consider carefully
STEPS = {}  # Currently not used, used when run methods get subdivided, these will be components of a macro
OPTIONS = {   # Can occur at global, macro, or testset level
  'name': (coerce_function, type, default, duplicate_allowed)
}

Need to think about options, but items will be iteratively run through each dictionary looking for matches and then handed to parse functions. For options, if duplicates are added, they'll be combined together.

For the command-line ("global") arguments, they need to get mapped to an option too, but it'll be more flexible.

This also acts as a useful and compatibility-maintaining precursor to the nested context structure from https://github.com/svanoort/pyresttest/issues/45.

Work Items

• [ ] Create macro registry in macros (but no loading yet) - these are name-to-macro-class mappings
  • We don't just bind to the parse function, we can do more with the class itself (besides calling its parse)
• [ ] Refactor testset parsing to use the Macro.parse static method, and to call it for the test/benchmark parsing
• [ ] Refactor to use common methods and scope-order-resolution for the macro fields via resolve_option in macros.py

[svanoort]

If we want to keep the class elements... each class can define its own parse table? Something like SYNTAX_ELEMENTS. Then we can use this to do parsing?

[svanoort]

Addendum: let's add the ability to add documentation strings to these! Then we can use a generator & template for syntax documentation. One less place to make changes when extending the framework.

[svanoort]

Proposal:

• Intermediate step: objects get their own field of configurable items, which the superconfigurator uses.
• Object may supply callback for configuration
• Standard library of configurations for basic test options (which cmdline can use)
  • HTTP options can be set at command line / testset / test / etc level (simply typed ones anyway)
  • Execution options too
  • Benchmark / test / etc have their own specifics
• Configuration handler can read from a set of global options and pass along a chain of responsibility for config items (each tries to handle the config, if missing, it fails)
• Use of closures/properties to get values where templating is used. --> May be better than use of simple dictionary scopes, b/c of encapsulation?
• Configurable objects have a field defining their configurable attributes.
• Scopes become a set of getarrs on the scope objects (or use of a resolve(context) method, similar to Context object fetching using variables for templating)

[svanoort]

For autodocumented code, use Sphinx, helpful links:

https://codeandchaos.wordpress.com/2012/07/30/sphinx-autodoc-tutorial-for-dummies/ http://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html https://pythonhosted.org/an_example_pypi_project/sphinx.html

[svanoort]

Kicking back to 1.8 milestone: collision with the Unicode/Python 3 compatibility/test coverage for that means this is just too much to take on at the moment.