Making JobOperation Private

[b-butler]

The JobOperation class is currently exposed to users for the primary purpose of using with submit_operations and run_operations #310. The only way to obtain JobOperation objects through the user interface is through the FlowProject.next_operations. The use case for this class is small, so I purpose making JobOperation a private class. The current public methods of JobOperation involve the id, command string, and querying the status. None of these, I believe, to be a compelling use case for keeping the class public.

Making JobOperation private would also more easily allow future refactoring.

[kidrahahjo]

@b-butler should I work on making JobOperation, SubmissionJobOperation, and next_operations private?

[vyasr]

@kidrahahjo I would hold off on this task for now. I'd like to hear feedback from some more of @glotzerlab/signac-committers before pushing forward too quickly.

[csadorf]

The original intention to expose some of this to the public API was to enable users to more easily develop their own execution and submission workflows, completely independent of the flow supported by the command line interface. I have so far not seen any real-world use cases for this. So with the goal to simplify things, I think it is totally fine to make this class (and all functions that directly use it) private.

[kidrahahjo]

@csadorf @vyasr @b-butler
Deprecation of these methods along with JobOperation and SubmissionJobOperation class is scheduled for this issue to get resolved.

1. next_operations
2. run_operations
3. submit_operations
4. script (This is because it takes in list of JobOperation instances and we are deprecating it now so this should also be deprecated)
5. completed_operations (This is just lying in the API without any internal use, I'm not sure why is this so)

I also feel like there's a need for deprecation get_job_status because of change in the way we fetch status for aggregation. After that implementation, we won't be using it for status update.