Add a doc example for workflow inputs and outputs

[liamhuber]

Closes #674

[liamhuber]

Don't worry about test failures; github is currently experiencing issues. Updates here

[coveralls]

Pull Request Test Coverage Report for Build 5071767682

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 12.946%

---

Totals
Change from base Build 5067334771:	0.0%
Covered Lines:	1655
Relevant Lines:	12784

---

💛 - Coveralls

[liamhuber]

@samwaseda bump.

[samwaseda]

I have the feeling that the fundamental examples (such as the ones showing how to access output) should be contained within a class and need not import other classes, because a) it makes it easier for the user to read; b) it makes it easier for the developer to keep doc strings up to date. I find it good that there’s this MD example in this doc, but I might prefer to have this new part executable without importing other classes (I presume it’s possible, right?)

[liamhuber]

I have the feeling that the fundamental examples (such as the ones showing how to access output) should be contained within a class and need not import other classes, because a) it makes it easier for the user to read; b) it makes it easier for the developer to keep doc strings up to date.

Hmm, I like the sentiment. I do think it's fair to import Node though, since that's the object that gets added to workflows. It is available directly on the workflow now (wf.add.Node), but I still think it's nice to see a wild node get added. Does that feel like a fair compromise?

I find it good that there’s this MD example in this doc, but I might prefer to have this new part executable without importing other classes (I presume it’s possible, right?)

It's great that you pushed on this! This docstring was actually out of date as (a) now the node libraries are available directly from the workflow, and (b) the default Node behaviour has changed to not run automatically, so the MD node needs some tweaking. Just pushing an update now.

We could also consider moving the "output" example further up so it doesn't depend on the "MD" example, which I like, but then we'd need an example higher up with sufficient complexity to have output worth looking at, which I dislike. At the end of the day I'm inclined to leave it as an addendum to MD, but if you feel strongly then I'm willing to slide it up.

[liamhuber]

Also -- and this is tangential and not something I want to address in this PR, but it comes back to our earlier conversation about naming so I wanted to point it out -- the MD node now reads CalcMd because the automatic name conversions can't (or at least are not clever enough to yet) support the double caps at the end for MD. Tab completion means this is not the end of the world, but I still really don't like it and it suggests maybe the node function-to-class conversion should be adjusted!

[samwaseda]

Hmm, I like the sentiment. I do think it's fair to import Node though, since that's the object that gets added to workflows. It is available directly on the workflow now (wf.add.Node), but I still think it's nice to see a wild node get added. Does that feel like a fair compromise?

Yeah given the close connection between Node and Workflow, it's justified to use it.

We could also consider moving the "output" example further up so it doesn't depend on the "MD" example, which I like, but then we'd need an example higher up with sufficient complexity to have output worth looking at, which I dislike. At the end of the day I'm inclined to leave it as an addendum to MD, but if you feel strongly then I'm willing to slide it up.

That would be perfect!

[liamhuber]

That would be perfect!

I'm happier with it now, good suggestions! Lmk if there's any more you think it needs.