This message was deleted.
# hamilton-help
s
This message was deleted.
p
Update from me - I can see that 9bdcaf1fbfa9183c3729d2cf368d582fc09f671e made changes to
hamilton/hamilton/function_modifiers/configuration.py
to include
config_used
as an arg to the
config
class constructor. It seems like this gives
None
when using a lambda/function for the config - eg
@config(some_func)
seems to now break things
For now I'm getting round the issue by doing
@config(some_func, config_used=[])
but this seems a little wrong in the long term...
e
Hey — will dig in more shortly but I think you’ve found a bug! We tightened the config requirement thinking it would be 100% backwards compatible, but it looks like it isnt. Will see if I can get a fix out/confirm my expectations today! Thanks for pointing this out :)
OK! I think I debugged it. Would love it if you’re OK trying it out (only difference should be to remove
config_used
): https://github.com/DAGWorks-Inc/hamilton/pull/144/. You can get it with:
pip install git+<https://github.com/dagworks-inc/hamilton.git@fix-config-base>
Otherwise I’ll be releasing
1.22.3
shortly 🙂
also would love to konw how you’re using
@config
(the base one, not `@when`/`@when_in`). I think we can build a cleaner version:
Copy code
@config.custom(lambda item_1, item_2=False : item_1 || item_1)
Which would mean that
item_1
and
item_2
are fields in the passed in
config
— this could be more readable and folows a similar paradigm to our only other config-direct decorator
@resolve
p
All working well, thanks for the quick fix!
At the moment I'm using the
@config
like this:
Copy code
def some_func(dag_config):
    value = dag_config.get("key")
    # any checks on value, returning bool

@config(some_func)
def dag_node(input):
    # normal node impl
So passing in the full config and extracting the values I need in the function itself.
e
You got it! And makes sense. These are checks that wouldn’t work with `@config.when`/`@config.when_in` (and the
when_not
and
when_not_in
variants)? If there’s a general pattern that would be useful to others I’m happy to add…
p
In this case, its just that the config I pass in is an object and I need to access various nested objects. I could just pull them all out when creating the config values but might end up being quite a long list so it seems to make more sense to keep it as an object and reference the attrs in the config lambda
e
Ahh got it — makes sense. Thanks!