Ensure the tasks state directory exists before saving state

[corranwebster]

Includes a test.

Fixes #488

[corranwebster]

Any idea why this isn't working as intended?

Not 100%. It that could mean the issue is actually in Canopy Data.

But there is something a bit dodgy about _initialize_application_home in that it isn't using self.state_location but a hard-coded path instead: if state_location changes after __init__ then you'll end up with this situation.

[mdickinson]

But there is something a bit dodgy about _initialize_application_home

Agreed: we should definitely be using self.state_location there. If I make that change, then the state directory is created as expected.

if state_location changes after __init__

Hmm. I suspect it shouldn't, in general. Do we have examples of applications that do this deliberately?

[corranwebster]

Hmm. I suspect it shouldn't, in general. Do we have examples of applications that do this deliberately?

I can see it might be used in testing. I'll dig a bit more into what Canopy Data is doing.

[corranwebster]

OK - this is at least a bit Canopy Data's fault - it is overriding _initialize_application_home and not calling super in it, so the tasks subdirectory is not being created.

I need to revise things, as I recall there being issues around all of this initialization code.

[corranwebster]

I think I have tracked this down - Canopy Data was not calling super because of #464. I think the correct fix is to remove Canopy Data's _initialize_application_home.

Closing (at least for now)

[mdickinson]

we should definitely be using self.state_location there

I've opened #490 for this.