is it possible to use

__post_init_post_parse__

in pydantic resources? my use case is that i want to construct a client property on the resource, but only want to supply the secrets. here's what i expect to be able to do:

from dagster import asset, materialize, ConfigurableResource

class FooResource(ConfigurableResource):
    api_key = "foo"

    def __post_init_post_parse__(self):
        self.client = get_client(self.api_key)

@asset
def thing(context, foo: FooResource):
    foo.client.do_something()


result = materialize([thing], resources={"foo": FooResource(api_key="test")})
print(result)

The spaghetti I’ve been cooking on my resources that works reasonably well is something like this:

class UtilsS3IOManager(ConfigurableIOManager):
    class Config:
        extra = "allow"
        frozen = False

    bucket: str

    @property
    def s3(self):
        if not hasattr(self, "_s3"):
            self._s3 = construct_s3_client()    
        return self._s3

ah, that's great

You need the

class Config

block with the

extra

and

frozen

params as I sent to make sure the Resources aren’t frozen

aah, i totally missed that

You can use PrivateAttr from pydantic for defining internal variables, looks slightly nicer tha hasattr. https://dagster.slack.com/archives/C01U954MEER/p1682319379488309?thread_ts=1682226946.013319&channel=C01U954MEER&message_ts=1682319379.488309

just my two cents, using the functools.cached_property seems to work pretty well and then you don't have to modify the class yourself

@Andras Somi this is much nicer! Will change mine to follow this as well

cc: @ben

Thanks all for your feedback - we’re considering changing our recommendations around state management in resources and providing corresponding lifecycle methods. An RFC for this change is up here - the PR description goes over the rationale + new patterns. If you have any input please leave it there!