add a "resolve from config" wrapper around the resolve decorator

[janhurst]

Add a small wrapper around resolve function modifier to "resolve from config"

Changes

Add a hamilton.function_modifiers.resolve_from_config hook that just passes ResolveAt.CONFIG_AVAILABLE flag to the original resolve class.

How I tested this

Have been using this as a small custom snippet (albeit not as a wrapper around the class) in some internal projects for quite a while. Its really just a convenience wrapper to make my pipeline code a little cleaner.

I've made a very small attempt to duplicate a relevant unit test.

Notes

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[elijahbenizzy]

Looking good! Minor change for docstring (and maybe name) then let's merge.

[elijahbenizzy]

Thought from @zilto -- would @resolve_at_config be cleaner?

Also, let's add a docstring then stick it in the decorators documentation.

See https://github.com/DAGWorks-Inc/hamilton/blob/main/docs/reference/decorators/resolve.rst -- should be easy!

[zilto]

I think @resolve_at_config better capture that it's a subset of @resolve where we set the value of ResolveAt to ConfigAvailable.

There's no other ResolveAt value, but I think the semantic make sense. I believe the name @resolve_at_config is an improvement over @resolve as it better communicate it's role during the Driver building.

[skrawcz]

🤔 just to voice my opinion that resolve_from_config doesn't need you to understand what the driver does, but it does help more clearly tie the connection that it comes from configuration passed in. Which I think for a new person to Hamilton that might be more intuitive, than resolve_at_config since now they need to understand what "at" might be referring to.

@janhurst thoughts on the name?

[janhurst]

realistically im pretty ambivalent...

i used @resolve_from_config for the reason @skrawcz mentioned... it described to me where the resolve was obtaining information

I think @resolve_at_config better capture that it's a subset of @resolve where we set the value of ResolveAt to ConfigAvailable.

the other way to look at this is to just default the when of @resolve to the only value it can use right now :) ... this is practically why i wrote my original wrapper functions anyway

[skrawcz]

the other way to look at this is to just default the when of @resolve to the only value it can use right now :) ... this is practically why i wrote my original wrapper functions anyway

We could do that. But would that be clear where the values come from? That's only reason we did such a verbose API in the first place -- to make it easier to read... 😆

[janhurst]

Looking good! Minor change for docstring (and maybe name) then let's merge.

added a little bit of a redirect to the @resolve docs... feedback greatly appreciated

[skrawcz]

This works for me.