When using both the sandbox stage-in mechanism and input target localization (e.g. through the law.decorator.localize() decorator), the localized targets are not existing.
It seems that, when localization is used, the stage-in is happening twice: once has part of the localization and once when task.input() is actually called. This leads to undesired side effects.
The reason is that the localize() decorator simply patches the input and output attributes (both methods) for the duration of the run() call, whereas the stage-in mechanism must hook __getattribute__ to provide the changed methods.
As a result, input() a calls _staged_input(), which is meant to call the original inputs() method. The latter is, however, the localized one such that the stage-in mechanism considers the localized targets as the original ones which is a bug.
The stage-in should always interact the with unchanged, original targets, and in this case, localization should deal with what the stage-in provides.
When using both the sandbox stage-in mechanism and input target localization (e.g. through the
law.decorator.localize()decorator), the localized targets are not existing.It seems that, when localization is used, the stage-in is happening twice: once has part of the localization and once when
task.input()is actually called. This leads to undesired side effects.The reason is that the
localize()decorator simply patches theinputandoutputattributes (both methods) for the duration of therun()call, whereas the stage-in mechanism must hook__getattribute__to provide the changed methods.As a result,
input()a calls_staged_input(), which is meant to call the originalinputs()method. The latter is, however, the localized one such that the stage-in mechanism considers the localized targets as the original ones which is a bug.The stage-in should always interact the with unchanged, original targets, and in this case, localization should deal with what the stage-in provides.