How to define a resource that exploit dagster PermissingConfig module to avoid having a fixed config schema?

To define a resource that uses

PermissiveConfig

to avoid having a fixed config schema, you can subclass

ConfigurableResource

and use

PermissiveConfig

as the base class for your configuration schema. This allows you to accept any additional fields without explicitly defining them in the schema, providing flexibility in your resource configuration. Here's an example from the documentation on how to define such a resource:

python from dagster import ConfigurableResource, PermissiveConfig  class MyResource(ConfigurableResource, PermissiveConfig):     # Define any required fields here     required_field: str      # The PermissiveConfig base class allows for additional fields     # that are not explicitly defined in the schema      def __init__(self, required_field, **kwargs):         self.required_field = required_field         # kwargs can contain any additional configuration  # Usage of the resource with additional config not explicitly defined in the schema my_resource_instance = MyResource(required_field="value", additional_config="extra")

In this example,

MyResource

is a subclass of both

ConfigurableResource

and

PermissiveConfig

. The

required_field

is explicitly defined, but any additional configuration can be passed in via

**kwargs

without needing to be defined in the schema. When you use this resource in your Dagster assets or jobs, you can provide additional configuration parameters that are not explicitly defined in the resource's schema, and they will be accepted due to the permissive nature of the configuration. Please note that while

PermissiveConfig

provides flexibility, it also means that you won't have strict validation on the additional fields, so you should use it judiciously and ensure that your resource implementation can handle unexpected configuration appropriately.