Not being able to have multiple differently configured resoruce_defs/keys in the same repo is a problem. loading_assets_from_module(keyprefix, groupname) breaks down as soon as I need different access configs for the supplied io managers. I want to give them all the same resources / io_manager but I would need for each prefix a different config. with_resources( … resources_by_key) breaks down because internally it also just overwrites by using configured on the resources. I would guess that this will be resolved with the upcoming change of having configured configs out of process. But am I right to assume I have to wait for that or is there some work around? I could see extending the loading_assets_from_module with some more features. • e.g. it would be useful to have output_prefix, and input_prefix separate so I can have a group depend on a different set of prefixes as I am using the prefix to also map to our own folder structure. • and resource_keys could have a postfix but really if they would just be configurable that would make more sense than having to namespace them.

+1 on this from me. The workaround I found is to change the resource names in the

required_resource_keys

and inside the function, which is not ideal, but works. See following:

@asset(required_resource_keys={"foo_one"})
def one(context):
    return context.resources.foo_one.run()

@asset(required_resource_keys={"foo_two"})
def two(context):
    return context.resources.foo_two.run()

@repository
def repo():
    return [*with_resources(
            definitions=[one, two],
            resource_defs={"foo_one": foo, "foo_two": foo},
            resource_config_by_key={"foo_one": {"config": {}},
                                    "foo_two": {"config": {}}})]

What I dislike about this is having to also change the resource attribute name. When the computations behind the assets are similar enough, I’m used to building them in a more abstracted way and simply passing different configs that lead to different assets (say I’m fetching campaigns or ad groups from GAds, here changing a few parameters in the config would already do the trick). Would be great to see some improvement there. For now I’m mostly sticking to `AssetMaterialization`s. SDAs are a fantastic concept and I’m excited to see it progress, but it’s not as flexible as I’d like.

Hi Samuel and Vinnie. Thanks for sharing valuable feedback here. I can definitely see the use case for a more dynamic configuration system within a repository that can provide different configurations for a resource used among multiple assets. For now, the solution that we came up with was similar to what Vinnie proposed above, something like this using the configured API:

return [*with_resources(
      definitions=[one, two],
      resource_defs={"foo_one": foo.configured({...}), "foo_two": foo.configured{...}})]

But that being said, it still doesn’t avoid the clunkiness of having to change the resource attribute name. Providing ways to inject unique config for each asset’s resources sounds like what we need here