Builder functions have limited access to anything but their input config and dependency entries. I can imagine the following may be also useful (not proposing to add all of this now, though):
- the runtime object
- the entry being created (in a wider sense)
- record additional outputs (generic files, images, TF logs, ...) [I want to make this]
- adding custom tags or information (logging?)
- performance of certain blocks in the computation (e.g. via context managers)
- online updates to progress (so it is seen in the DB and dashboard)
- the set of all requested dependencies
- get builder by name (from runtime)
This would likely be merged into _CONTEXT functionality.
Open question: how should builder fn get the context?
- First argument - IMO ugly and cumbersome for simpler functions, needs some more argument magic
- Function of
orco, e.g. orco.ctx() - an explicit call (people will want to cache it) but semantically clean
- Module "attribute" like
orco.ctx - even nicer, but modules can't have properties with getters.
- We can have
orco.ctx be a global proxy that redirects all attr access to thread-local objects ... buut may not be worth the extra fancy
Builder functions have limited access to anything but their input config and dependency entries. I can imagine the following may be also useful (not proposing to add all of this now, though):
This would likely be merged into
_CONTEXTfunctionality.Open question: how should builder fn get the context?
orco, e.g.orco.ctx()- an explicit call (people will want to cache it) but semantically cleanorco.ctx- even nicer, but modules can't have properties with getters.orco.ctxbe a global proxy that redirects all attr access to thread-local objects ... buut may not be worth the extra fancy