Added run_jobs_using_params()

[mitkotak]

Allows us to do something like

cybergis.run_job_using_params([{"input_a" : 50, "input_b" : "foo"}, {"input_a" : 100, "input_b" : "bar"}])

[alexandermichels]

@mitkotak I have two tasks on this PR:

1. Can you check that this all still works with the big changes we pushed to the Core and SDK?
2. Determine if this PR solves this issue: [FeatureRequest-IGUIDE]Allow to programmatically pre-fill values for model-specific parameters #45

Thanks!

[alexandermichels]

Just tested this functionality out, It's pretty cool!

There are a few changes we need to make though. I think the way this will be used is to test a variety of parameters/settings to ensure that the job works, so reading from one hard-coded file isn't going to work. I think we should probably remove the code that reads from the JSON if the file exists.

Ideally the solution we want is for the user to provide a path to a JSON or a JSON loaded as a dict to a function like "run_job_using_params(...)" that takes in the dictionary of parameters and submits the job. I don't think we need to add it to the UI right now because this is mostly for model developers and the important part is that the functionality exists.

Other notes for when we come back to this functionality/future work (aka you don't need to do this for this PR):

1. The save parameters button would be better if we could choose the path/filename, but that's okay for now. We will just have user's move the file/rename it themselves.
2. Once we have a function like "run_job_using_params(...)" we will probably also want "run_jobs_using_params(...)" which takes a list of paths/dicts, submits each job, and when the job finishes, resets the UI and submits the next one.
3. Eventually, we might want to make a "dev" flag in the "show_ui(..)" function which only shows the "Save Parameters" button and a tab for running many jobs if dev==True.

[alexandermichels]

Overall the code is good and seems to work (ran hello world and pysal-access, then restored the job from the UI to check on them). We need to meet with Drew though to figure out how this would be used and if this would be enough. I'm assuming that we will at the very least need to give indicators on the status of the jobs (running/error/completed) or something for this to be useful for end-users.

[alexandermichels]

It seems this is how the user would pass in the "job"/"model" which will probably not be intuitive to them.

[mitkotak]

Yup I will handle that in ParamAccumulator (Will maybe change the name to something else since its handling "job"/"mode" preprocessing as well).

[alexandermichels]

This makes sense and works (tested it with a couple of jobs), but we may also need to report the status of jobs. I imagine the way this is going to be used, end-users will want to know that all of their jobs ran and didn't throw errors. Maybe next week we can sit down with Drew and get feedback on that.

[alexandermichels]

Not quite understanding what the role of this helper class is at this point. It seems to be a wrapper around a dictionary that doesn't provide any additional functionality.

[mitkotak]

Yeah the role for that class is to handle all of the input preprocessing that might be needed. For e.g. json paths ( working on it rn ) or some other input format that we might wanna support.

[alexandermichels]

Tested and seems to work. Not sure how this slipped through the cracks, but approving now.