Make input partitions methods based on asset key not input name

[jamiedemaria]

Summary & Motivation

One of the changes I'd like to make to the partition methods on the context is to allow them to accept CoercibleToAssetKey rather than input name. This will mean users wont need to map back and forth between asset key and input name and will remove the I/O manager-centric term "input".

To achieve this, the top level partition functions in the StepExecutionContext need to accept asset keys rather then input name. Right now the pattern is like this

class OpExecutionContext:

   def asset_partition_key_for_input(input_name):
        self.step_execution_context.asset_partition_key_for_input(input_name)

class StepExecutionContext:
    def asset_partition_key_for_input(input_name):
         asset_key = self.get_asset_key_for_input(input_name)
         ...

And I'd like it to be like this:

class OpExecutionContext:

   def asset_partition_key_for_input(input_name):
       asset_key = self.step_execution_context.get_asset_key_for_input(input_name)
        self.step_execution_context.asset_partition_key_for_asset(asset_key)

class StepExecutionContext:
    def asset_partition_key_for_asset(asset_key):
         ...

So that we can support this in AssetExecutionContext

class AssetExecutionContext:

   def partition_key_for_upstream_asset(asset_key: CoercibleToAssetKey):
        self.step_execution_context.asset_partition_key_for_asset(AssetKey.from_coercible(asset_key))

How I Tested These Changes

[jamiedemaria]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

• master
  • PR Only have one kind of context for direct invocation #17554
    • PR duplicate op context methods on asset context  #18573
      • PR deprecate methods on AssetExecutionContext that can be found via the DagsterRun object #17339
        • PR Direct invocation asset execution context #18549
          • PR deprecate asset_partition_*_for_output on AssetExecutionContext #19436
            • PR [docs] remove asset_partition_*_for_output from docs #19437
              • PR deprecate op related methods from AssetExecutionContext #19441
          • PR Make upstream asset materialization events available on the context #18971
            • PR [wip] store the tags fetched by data versioning so we can use them for upath io manager #19324
              • PR [UPath I/O managers] special case handling of None outputs #18820
            • PR Make input partitions methods based on asset key not input name #19027 👈
              • PR Support partitioned assets for fetching latest AssetMaterializations #19286
              • PR [do not merge] base example to showcase new apis #19199
                • PR [prototype] sub-context for each upstream dependency  #19283
                • PR [prototype] AssetExecutionContext partition methods on sub context #19236
                • PR [prototype] AssetExecutionContext partition methods given as named tuple #19037
                • PR [prototype] AssetExecutionContext partition methods directly on the context #19032
            • PR [wip] two execution contexts with minimal changes #18543
              • PR [wip] see wht needs to change when asset context is no longer an op context #18553
        • PR support Asset and Op ExecutionContexts in standard execution path #17972
          • PR [wip] add AssetExecutionContext to direct invocation #18044

This stack of pull requests is managed by Graphite.

[jamiedemaria]

What's the deprecation policy for these methods on StepExecutionContext? Are they considered public? If so i'll retain versions of these methods that just call their asset_key based counterparts after converting the input name to an asset_key

[sryza]

Methods are only public if:

• They're on a publicly-exported class
• They have the @public decorator

[jamiedemaria]

ok - these are public then. I'll add the method names back

[sryza]

This one at least doesn't have the @public decorator, right?

[jamiedemaria]

yeah, but StepExecutionContext is publicly exported class.

[jamiedemaria]

wait... was the list of conditions an AND not an OR?

[sryza]

ah oops yes, an AND

[jamiedemaria]

ok i can revert that commit lol

[jamiedemaria]

converting back to draft to get this out of review queues until context work is re-prioritized