Docs: Further clarification on how serialization impacts where imports need to be

[Andrew-S-Rosen]

Jotting this down from Slack so I/we don't forget:

Me:

The current docs as-is are kind of confusing with regards to the need to put import statements in PythonApp definitions. there's some pretty strong-worded statements about always needing to do so, but that's not the case (e.g. if you're making a package that will be installable). i'll give this some thought too. I think Logan Ward and I discussed this at one point

@WardLT:

Yea, we really do need to clarify how serialization works to explain that

[benclifford]

I'm mostly interested in cases where having too many imports of this form is actively harmful

[Andrew-S-Rosen]

@benclifford: I can provide some background. When I was first exploring which workflow engine to consider for my Python package, I was looking for a package where I didn't really have to change how I wrote my code --- just decorate and move on (for the most part). When I opened up the Parsl docs, I was originally turned off by the fact that it seemed like I needed to move all my import statements into the PythonApp definitions. For better or for worse, I closed the tab and moved on. Of course, I came back later and learned that this "requirement" really depends on the context.

So, I can't really see how it'd be harmful, but I do think it could be considered annoying (particularly when it's not actually needed). The docs as-written right now make it seem like it's a hard-and-fast rule when that's not the case.