https://dagster.io/ logo
#ask-community
Title
# ask-community
m

Mykola Palamarchuk

04/01/2022, 7:57 AM
Hi! Is there a way to redefine required resource key? Imaginary use case: you have two `s3_pickle_io_manager`s which should depend on their own `s3_resource`s clients.
s

Samuel Stütz

04/01/2022, 8:33 AM
I think that is the point of the keys, make different ones.
Copy code
resource_defs={
        "bq_proj1": bigquery_resource,
        "bq_proj2": bigquery_resource,
        "gcs_me": gcs_resource,
        "gcs_other": gcs_resource,
}
then in the op
Copy code
@op(required_resource_keys={'gcs_other'})
io_manager is just a standard one the way I understand it but https://docs.dagster.io/concepts/io-management/io-managers#per-output-io-manager
m

Mykola Palamarchuk

04/01/2022, 9:31 AM
@Samuel Stütz how would you provide "bq_proj2" to "gcs_other" as a dependency?
s

Samuel Stütz

04/01/2022, 10:17 AM
go to gcs_pickle_io_manager definiton copy paste the code then change in the
@resource
the required resource keys to not gcs but gcs_other
So you refine your own @resource essentially.
m

Mykola Palamarchuk

04/01/2022, 11:16 AM
That means you have to copy-paste the whole existing resource definition to have the change in the key. I wish there was a way to avoid copy-paste here. Something like:
Copy code
resource_defs={
        "s3": s3_resource,
        "s3_next": s3_resource,
        "io_manager": s3_pickle_io_manager, # will depend on "s3" by default
        "io_manager_next": s3_pickle_io_manager.rename_requirements({"s3": "s3_next"})
}
o

owen

04/01/2022, 4:24 PM
hi @Mykola Palamarchuk -- as of now, there's not a way to do this, and Samuel's answer is probably the quickest workaround at the moment. One thing that makes this slightly less unpalatable (although, I'll admit it's still ugly) is that the resource definition functions are usually pretty lightweight. Another, potentially more aesthetic option would be to create a new resource function that takes configuration for both the original s3 resource and the io_manager at the same time, and instantiates the s3 session (which originally would have come from the s3 resource) and passes it into the io manager. This way, you circumvent having required resource keys anywhere, and can create as many of these io managers as you want in a single job.