-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add AssetSpec and specs on @multi_asset #15674
add AssetSpec and specs on @multi_asset #15674
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
5b62c14
to
ea13d08
Compare
5210e49
to
21d64bd
Compare
ea13d08
to
11b175c
Compare
21d64bd
to
55ce94f
Compare
11b175c
to
6b6e29a
Compare
55ce94f
to
f472032
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good start.
I think the term "report" is good instead of "log". 👍🏻
We have an important decision to make in terms of whether the function is report_asset_materialization
or add_asset_materialization_metadata
(or something shorter).
report_asset_materialization
is more obvious and predictable; add_asset_materialization_metadata
could be more convenient
Also add a test where we have asset keys "a/c" and "b/c" so we catch the collision case.
python_modules/dagster/dagster/_core/definitions/decorators/asset_decorator.py
Outdated
Show resolved
Hide resolved
python_modules/dagster/dagster/_core/execution/context/compute.py
Outdated
Show resolved
Hide resolved
python_modules/dagster/dagster_tests/asset_defs_tests/test_assets.py
Outdated
Show resolved
Hide resolved
360c246
to
b0178b3
Compare
f472032
to
0062ab0
Compare
b0178b3
to
8abf8c4
Compare
a994591
to
31f94ea
Compare
31f94ea
to
1400b6d
Compare
python_modules/dagster/dagster/_core/execution/context/compute.py
Outdated
Show resolved
Hide resolved
1400b6d
to
d99d0c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes based on ominous comments
Union[ | ||
CoercibleToAssetKey, | ||
"AssetSpec", | ||
# AssetsDefinition, if only one-key trick |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
support it or or delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I argue for supporting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also does this need a sep docstring? What's our docstring policy for namedtuples with __new__
overriden?
python_modules/dagster/dagster/_core/definitions/decorators/asset_decorator.py
Outdated
Show resolved
Hide resolved
python_modules/dagster/dagster/_core/definitions/decorators/asset_decorator.py
Outdated
Show resolved
Hide resolved
python_modules/dagster/dagster/_core/definitions/decorators/asset_decorator.py
Outdated
Show resolved
Hide resolved
4ac03cf
to
d69be9b
Compare
bbc0e0a
to
cf80dc1
Compare
Deploy preview for dagit-core-storybook ready! ✅ Preview Built with commit 2598143. |
d69be9b
to
00c9050
Compare
cf80dc1
to
6aad503
Compare
output_name, | ||
Out( | ||
Nothing, | ||
is_required=not can_subset, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is an interesting design choice worthy of scrutiny - the optionality of all outputs is controlled by declaring can_subset
, a sort of all-or-nothing opt-in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we need to support multi_asset
with one of the assets being optional, but not subset-able
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what you have here is not sufficient
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts on how that should be expressed? Should it be a property of the AssetSpec
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attaching it to AssetSpec
feels a bit weird. Seems like it should be a property of the computation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current thinking is using specs is for un-managed IO so no interactions with IO managers and no need to set the key. Are we missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I guess I had been assuming that we'd basically deprecate AssetOut
, but it sounds like we'll be supporting both? Not so bad, just different from what I was expecting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah a huge (primary?) goal is to not have anything io-manager or dagster-type related on AssetSpec
. That is a separate "layer". It's existence would be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it - makes sense. This makes me continue to dream of having some sort of storage concept that applies to assets even if we're not managing the output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok the PR is now updated to include a skippable
property on AssetSpec
that says
skippable (bool): Whether this asset can be omitted during materialization, causing downstream
dependencies to skip.
output_name, | ||
Out( | ||
Nothing, | ||
is_required=not can_subset, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well specs drop io_manager_key
and dagster_type
, so code_version
is the last odd ball but i think can be improved with rename/docstring cleanup
00c9050
to
36d9651
Compare
2598143
to
1893f3e
Compare
asset is intended to be. | ||
auto_materialize_policy (Optional[AutoMaterializePolicy]): AutoMaterializePolicy to apply to | ||
the specified asset. | ||
backfill_policy (Optional[BackfillPolicy]): BackfillPolicy to apply to the specified asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should go on the op, not on the asset.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, will rm
("description", PublicAttr[Optional[str]]), | ||
("metadata", PublicAttr[Optional[Mapping[str, Any]]]), | ||
("group_name", PublicAttr[Optional[str]]), | ||
("skippable", PublicAttr[bool]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a reasonable name to me.
"_AssetSpec", | ||
[ | ||
("asset_key", PublicAttr[AssetKey]), | ||
("deps", PublicAttr[AbstractSet[AssetKey]]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The behavior for multi-assets currently is that, if the internal_asset_deps
parameter is not provided, every output asset is assumed to depend on every input asset.
Is my understanding correct that here we'd be requiring users to specify this all-to-all dependency on their own?
I assume this means that if you're using asset specs then you can't also specify the deps
param of @multi_asset
? What about if there are parameter inputs? Are those allowed, and, if so, how do those get hooked up specs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ill get some tests written up and try to flesh this out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, PR updated with the idea that AssetSpec.deps
is the only way to specify dependencies
can't also specify the deps param of @multi_asset?
correct. The AssetSpec.deps
that are not internal to the @multi_asset
form the "deps" except when...
What about if there are parameter inputs? Are those allowed, and, if so, how do those get hooked up specs?
you can have parameter inputs, but there must be a corresponding AssetSpec.deps
entry for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it - those semantics make sense to me. A little worried that "updated with the idea that AssetSpec.deps is the only way to specify dependencies" will be too cumbersome, but I don't have a great alternative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya same. We can always relax constraints in the future if we figure out something we like.
36d9651
to
8b520e7
Compare
5a0affc
to
47cc09c
Compare
should i mark these things explicitly as experimental for now? |
@alangenfeld yeah experimental |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sure to fixup docs but let's do this 👍🏻
python_modules/dagster/dagster/_core/definitions/decorators/asset_decorator.py
Outdated
Show resolved
Hide resolved
8b520e7
to
9824b63
Compare
47cc09c
to
3c9258d
Compare
changed up docs to deprioritize specs while its experimental |
3c9258d
to
beaf5aa
Compare
Introduces an
AssetSpec
class for declaring the assets that are materialized instead of usingAssetOut
. This mirrors the newly added setup ofAssetCheckSpec
andcheck_specs
from #15928 and #15948.This is motivated by providing cleaner API surface for users who do not need to leverage Dagsters IO management, and therefor are better served with APIs that are conceptually "output-free".
How I Tested These Changes
added tests