If you try to leverage .working_directory inside a macro definition, it is sensitive to whether or not that macro is being intialized/used with(out) a parent. This is because the working_directory leverages the semantic path to create a file path, but once created it gets frozen. So if you create then parent, the working directory will miss out on all the path stuff from the (eventual) parent. Because of the order of setup, if you pass the parent at initialization, it works ok.
Example:
If we instantiate the macro by itself, then assign it to a workflow, we get the wrong path
TBH, I'm not actually sure what behaviour I want here. The working directory/semantic path interaction is not something I have totally worked out in my head yet. But the current behaviour is definitely a nasty gotcha.
If you try to leverage
.working_directory
inside a macro definition, it is sensitive to whether or not that macro is being intialized/used with(out) a parent. This is because theworking_directory
leverages the semantic path to create a file path, but once created it gets frozen. So if you create then parent, the working directory will miss out on all the path stuff from the (eventual) parent. Because of the order of setup, if you pass the parent at initialization, it works ok.Example:
If we instantiate the macro by itself, then assign it to a workflow, we get the wrong path
Desired(???):
{'m__path': '/Users/huber/work/pyiron/notebooks/create_then_parent/no_parent'}
But by passing the workflow as a parent at initialization everything is ok
TBH, I'm not actually sure what behaviour I want here. The working directory/semantic path interaction is not something I have totally worked out in my head yet. But the current behaviour is definitely a nasty gotcha.