Hi,
I have a couple of comments here.
First, you should give BarTask a different _fw_name than footask (or don't set the _fw_name at all, in which case it defaults to package_name.class_name, or use the @explicit_serialize decorator instead).
Second, I am not sure that you need to call PyTask inside of the "run_task" method of footask. The run_task method can contain any Python code, not just FireTasks. Perhaps you are using PyTask so that you can use the stored_data_varname. In that case, I would still suggest just calling the Python routines you want directly, and then storing the desired variables at the end using a FWAction (see example #1 below)
Currently, the stored_data_varname is meant to be more "archival" (look it up later for reference) than a variable that is meant to affect the execution of the workflow. In order to do the latter, I would suggest one of the following:
1) (recommended) don't use PyTask, and just use a FWAction at the end that both stores and passes on the variable:
def run_task(fw_spec):
var_foo = math.exp(3,2)
return FWAction(update_spec={"foo":var_foo}, stored_data={"foo":var_foo})
Then, the next FireTask will be able to access the variable using the
This is due to the update_spec part. Actually, you might not need the stored_data at all in this case. The value of foo will be stored in the spec of the next FireWork due to update_spec. A few more details about this are in the following tutorials:
2) (not recommended). Remember, there is no simple way to access stored_data_varname. You will need to query the launches database to get this information. You can get access to a launchpad object by setting the following in your fw_spec:
{"_add_launchpad_and_fw_id": True}
Then, your firetask will have access to a "launchpad" and "fw_id" internal variables, i.e. inside of run_task() you will be able to access self.launchpad and self.fw_id. Then you can do something like:
stored_data = self.launchpad.launches.find({"fw_id": self.fw_id}, {"action.stored_data":1})['action']['stored_data']
*after* storing your data. Again, I don't recommend this technique.
Finally, if there is a certain way you'd *want* things to work, feel free to suggest it. We can always look into adding it if it makes sense in a general way.