Wizard rewrite

[dwhswenson]

This is a pretty significant rewrite of the wizard, introduced in #41. Main goals here:

• Use new plugin infrastructure to make this more modular.
• Wrap things from compiling (#43) whenever possible (instead of duplicating code).
• Make it much easier to set up a wizard once a compiler plugin has already been written.
• Better support for interactive help and other commands.

As with #43, this is only partially complete. It goes up to the state definitions. Things above that (networks, etc.) still work, but haven't been migrated to the new approach.

[codecov]

Codecov Report

Merging #54 (1399860) into main (f8ed965) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              main       #54    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           45        51     +6     
  Lines         1766      2113   +347     
==========================================
+ Hits          1766      2113   +347     

Impacted Files	Coverage Δ
paths_cli/plugin_management.py	100.00% <ø> (ø)
paths_cli/wizard/joke.py	100.00% <ø> (ø)
paths_cli/commands/wizard.py	100.00% <100.00%> (ø)
paths_cli/compiling/volumes.py	100.00% <100.00%> (ø)
paths_cli/wizard/cvs.py	100.00% <100.00%> (ø)
paths_cli/wizard/engines.py	100.00% <100.00%> (ø)
paths_cli/wizard/helper.py	100.00% <100.00%> (ø)
paths_cli/wizard/load_from_ops.py	100.00% <100.00%> (ø)
paths_cli/wizard/openmm.py	100.00% <100.00%> (ø)
paths_cli/wizard/parameters.py	100.00% <100.00%> (ø)
... and 10 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8ed965...1399860. Read the comment docs.

[dwhswenson]

This is ready for review and comment. I will leave it open for at least 120 hours, merging no earlier than Sun 31 Oct 18:00 GMT (14:00 my local).

I haven't cleared the CodeClimate complaints so that they'll be available to assist review. Here are my thoughts on those. They fall into 3 categories:

1. Cognitive complexity greater than 5, less than 10. I generally don't worry about this -- 5 is an ideal target, but not a hard maximum for me.
2. Too many lines of code. The files where this is happening are things I don't think I want to split up (especially plugin_classes.py), though I'd be open to suggestions if there's a better way to manage this. Some of wizard.py will probably be removed as I refactor to reduce code duplication.
3. Too many arguments (frequently for __init__). I'm using a software design style where these classes are process templates, so there are, in fact, many parameters. Many of those parameters are just what the wizard is supposed to say different stages of the process. The idea here is that, even with many parameters, it's extremely straightforward for a user to create a plugin. Look at the OpenMM plugin and the CVDefinedVolume plugin for examples -- when most of the work already exists in one of the "compiling" plugins, all you have to do is fill in what the Wizard is supposed to say. I think it is better to have a template like this, with a lot of parameters, than to ask developers to write all the code that interacts with the wizard as well (although that is also an option, and I do that when the mapping to compiler plugins isn't as straightforward.)

[dwhswenson]

Note: I've posted issue #57 with a list of known issues that need to be improved in the wizard. I'm cutting off additional functionality in this PR where it is now, since it's already too large. The topics in #57 can be part of smaller, more manageable PRs for review.

[sroet]

Mostly style/leftover debug code LGTM otherwise

[dwhswenson]

@sroet : Thanks for the first round of review -- now this is ready for a second round. I think that all issues you brought up have been addressed except for the use of the term "subvolume", on which I'm open to suggestions for improvements.

Also, please let me know your thoughts on the CodeClimate issues and my justifications for ignoring them. This is the sort of thing where I really appreciate someone else looking over the code and telling me if the CodeClimate issues are actually causing readability problems (and maybe suggest ways around it if they are).

[sroet]

@sroet : Thanks for the first round of review -- now this is ready for a second round. I think that all issues you brought up have been addressed except for the use of the term "subvolume", on which I'm open to suggestions for improvements.

I would go for "input volume"

Also, please let me know your thoughts on the CodeClimate issues and my justifications for ignoring them. This is the sort of thing where I really appreciate someone else looking over the code and telling me if the CodeClimate issues are actually causing readability problems (and maybe suggest ways around it if they are).

The reasoning for ignoring these codeclimate issues seems fine to me.

I will not have any reliable internet until monday (going to a cabin), but I can have another look after I am back if it is still required ;)

[dwhswenson]

I will not have any reliable internet until monday (going to a cabin), but I can have another look after I am back if it is still required ;)

If everything else is resolved, I'll permit the CodeClimate issues and make the change regarding "subvolume" (perhaps "input volume you define now", given context?) Then I may go ahead and merge this -- don't think it would need your eyes again, and I'd rather have you show up on Monday to a bunch of PRs that build on the work here. 😉