Developer experience feedback - type annotations for

context.resources

,

context.op_config

, etc? I have no idea if this is at all feasible (likely not), but currently all type information is lost on these objects. Just had a silly typo on a function within a custom resource - would have been much easier to catch (or not have in the first place) if auto-suggest from VS Code was functioning correctly.

This is also something I’d like ALOT. It’s already quite a bit better than the airflow experience of passing jinja templates strings around that magically turn into malformed dictionaries laugh cry , but pushing this a bit further would make it even nicer. I think something like this may be possible but may require some substantial code changes. Currently ResourceDefinitions take in config_schema and required_resource_keys as a “coercible to config schema” and “abstract set [str]” respectively. Changing these to also support something like a typeddict (from say typing_extensions for python version compatibility), would allow resource def to have some typing information. I think however exposing that to the type system at the end is more complicated. You’d probably need to do something with generics and typevars to get this to work well, and that may or may not work well with the current annotation based patterns. I’m not sure as I’m also learning more of these python things myself 🙂 But, something like:

class MyRequiredResourceDefs(RequiredResources):
    snowflake : SnowflakeResource
    aws_parameter_resource: AwsParamResource

@asset(required_resources=MyRequiredResourceDefs)
def my_asset():
    ...

would be a very nice pattern to have. IMO.

I’ve done a lot of typing improvements on Dagster and recognize this as a significant weak point. I will look into it: @Dagster Bot issue Typing support for user-supplied data on

OpExecutionContext

Created issue at: https://github.com/dagster-io/dagster/issues/10274

cc: @schrockn