Closed corranwebster closed 1 year ago
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.
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?
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.
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.
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)
we should definitely be using
self.state_location
there
I've opened #490 for this.
Includes a test.
Fixes #488