Zen-metas in the iterative builder pattern

[gabmis]

Hi @rsokl, my whole team has been using hydra zen and we're loving it!
I have one question though.
Currently, when building iteratively (builds(builds(..)) I believe zen-metas are lost from one iteration to another.
Is there a reason for that? On our side, it's preventing us from using zen-metas at all.
If unclear, I'd be happy to provide a code snippet. If untrue, my bad for not double checking.

[rsokl]

Hi @gabmis thanks for bringing this to my attention. Indeed it looks like the flat-target pattern is just broken for zen-meta fields (or anything else that leverages zen-processing features).

I may have a compatibility-preserving fix that at least makes it possible to leverage iterative builds patterns with zen-meta fields. Although it won't be "automatic" - so to speak - you will need to use inheritance too (see the PR).

Because this is not compat-breaking I could include it in v0.12.2. If I were to make zen-processing features "just work" here (no inheritance) it would be a lot more work and would be compat-breaking, thus not be available until v0.13.

Let me know what you think.

P.S. Glad you all are loving hydra-zen 😄

[gabmis]

Thank you very much @rsokl for answering so quickly and coming up with a solution.

I guess you're asking whether using inheritance is satisfactory enough for us. My answer is yes and no.

Yes, because one of our use-case is to have, at the top-level of our training configuration, placeholder fields which we can easily reference from anywhere. An example of that is our datasets field which contains configurations for our dataset objects (one for each stage) which are referenced in both our LightningDataModule (assuming you're familiar with pytorch-lightning) and our evaluation callbacks.
For that use case, our current fix was to replace builds(train_task, zen_meta={"dataset": MISSING}) with builds(dict, the-arguments-of-train_task, datasets=MISSING) (not so zen I know). This will have the sometimes very undesirable effect of instantiating an extra (useless) copy of our datasets.
Note that datasets here are mainly annotations and metadata along with paths to the underlying images, not the heaviest of our data assets but can grow quite large in some use cases. For these use cases, precisely, we would resort to your inheritance-based solution to avoid the large cost I just described.

No, because configs are already somewhat convoluted objects so we want to keep them as simple as possible and as short as possible. So, outside of that particular use case we'd probably wait for the no-inheritance fix.

Hope this helps in your decision making and sorry for the unnecessarily long write-up 😅
Also, if we're doing it wrong please let us know 😂

[rsokl]

Sorry for delayed response (just moved and am having a baby soon 😅).

Will try to write up my thoughts on this sometime this weekend.

[rsokl]

Sorry for the radio silence here. I have merged #638 so that iterative-builds is not so broken with zen-processing features (e.g. meta fields). I will cut make a pre-release soon so that this fix is pip-installable for you and your teams.

As I mentioned in your other post, I decided that I cannot add additional complexity to builds and I think it makes more sense for you to build your own "iterative-builds" abstraction over builds. This will likely be much easier for you to get the behavior you are looking for. I'm always happy to field questions or provide guidance where it might be useful (although please excuse the gaps in replies!)

[rsokl]

I published 0.13.0rc1 yesterday, which includes the #638 (along with some cool new features!): https://mit-ll-responsible-ai.github.io/hydra-zen/changes.html#rc1-2024-04-01

[gabmis]

As said in my other post, thanks a lot for your help!! Thanks for the new release, will have a look at those new features :)