No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Trying to use Automation API to disable the default providers, but the `set_config()` method doesn't support using a path key?
```    stack.set_config("pulumi:disable-default-providers[0]", auto.ConfigValue("*"))```

Results in a literal config with [0] in its name.. but if I use --path on the cli I can force it to a list of string... is there a more correct way to do this?? setting complex types via automation?

<https://github.com/pulumi/pulumi/issues/5506#issuecomment-840796967> is this still relevant, and the value should just be passed in as a json dumps?

I guess subprocessing out to the CLI is the only way -- very disappointing :disappointed: Looks like it could be possible to extend the LocalWorkspace class though and add a `set_path_config` method or something.

<@UCWG26BH7> <https://github.com/pulumi/pulumi/commit/56e12e9140b5a7ec41aa7215588685b1ca8db889> are commits like these, where someone adds these automation API extras, generated, or does each languages' SDK require its own adaptation?
Basically, I didn't see any comments about pulumigen in these files, so I wasn't sure how that worked, contributing-wise?

Cool thanks for that clarification Lee. :+1:

<@UCWG26BH7> for what it's worth, I found myself making a helper method that did this:
```def disable_default_providers(stack: auto.Stack) -&gt; None:
    """
    Runs the pulumi cmd to disable all default providers.
    """
    stack._run_pulumi_cmd_sync(
        args=[
            "config",
            "set",
            "--path",
            "pulumi:disable-default-providers[0]",
            "*",
        ]
    )```

I wonder if it makes sense to open up the `_run_pulumi_cmd_sync` method to be 'public' for custom use-cases where the context of the stack would be beneficial, but there's no built in support for handling some of the CLI components.

Obviously there'd be some warranty here of "here be dragons, and you could break the intended context some how"