https://dagster.io/ logo
#ask-community
Title
# ask-community
d

Dennis Schwartz (he/him)

03/07/2024, 12:01 PM
Hi all! I have a quick question before I go too deep into the weeds with this: Is it possible to have assets as inputs which are defined in a different code location? I have Asset A in code location X, I now want to write an Asset B which takes the generated data from Asset A, but B is defined in a different code location Y. I have to have two locations because of incompatible Python environments and I can't make it work. I get the error:
Copy code
Input asset 'A' for asset 'B' is not produced by any of the provided asset ops and is not one of the provided sources
z

Zach

03/07/2024, 3:20 PM
You used to do this with SourceAssets (example somewhat similar to your situation here), but Dagster has been removing docs for that feature and pushing people toward external assets, so I'm not sure what the canonical way to do this is now
I made a Github Discussion here because I'm also interested in the up-to-date answer to this
d

Dennis Schwartz (he/him)

03/07/2024, 3:25 PM
Thanks! Yeah I'm falling back to using SourceAssets at the moment. But they can only be specified as
deps
not
ins
, so I can't actually access the output of the upstream assets. It seems that SourceAssets and ExternalAssets are geared towards processes where the data is not generated by Dagster at all, but what I'm looking at is a case where the upstream is generated by Dagster in the same deployment, just in a separate code location. I think I have a workaround now where I use the DagsterInstance to get the latest materialisations of the upstream asset via its name and get the data from there. But it's very hacky.
Ah amazing! I was planning to do this as well later 🙂
z

Zach

03/07/2024, 3:40 PM
Ah cool, if you have some time I'd love to hear in a little more detail how you're using the materialization data from the DagsterInstance to get the actual data to load.
I too have felt like the cross-code-location asset deps issue has never really be satisfactorily resolved and it seems like there hasn't been a ton of progress toward a great solution
d

Dennis Schwartz (he/him)

03/07/2024, 5:52 PM
I've added my workaround to the discussion you posted above 🙂
5 Views