minor changes but bouncing back to your queue
Thu, Apr 15
Super excited for this change. Big step forward. Thanks @cdecarolis for working through this. Will let others approve.
Wed, Apr 14
I'd love to get this in for tmrw's release. Feel free to take stab at my proposed refactor or not. Your discretion.
Tue, Apr 13
To be clear in vanilla solids you still have to raise these right?
Mon, Apr 12
Sat, Apr 10
Sun, Apr 4
Tue, Mar 30
Thu, Mar 25
Mon, Mar 22
Slightly concerned about possible weird aesthetics of whitespace depending on how the docstrings are slurped and how we handle whitespace on the client. But given that we do this for inputs it makes sense
Fri, Mar 19
Mar 18 2021
Having both feels very painful. Why can't they be consolidated?
Mar 17 2021
I think this is good and we should highlight it in the release notes. "You no longer need to use DagsterPythonObjectType or make_dagster_type_usable_as_WAIT_WHY_DO_I_NEED_TO_TYPE_THIS"
ah ok. curious to hear @prha's thoughts on the diff btwn those two
q mgmt. this is very stale. if it is still in reviewable state bounce back and i'll review
I think the context construction pathways are so intricate and tied to internal implementations that they should be considered private
Yeah I think the core point of contention is whether or not the constructor for contexts should be considered private. I think they should. We could even go the point where we change *Context classes to be abstract classes only.
I support landing it. Can we add docs in the same diff (or another one concurrently?)
I think this is good. My final question is what we should default the instance to
not perfect but better than nothing
huge fan thanks
clearing out queue. what is the plan with this?
I'd like to see docs changes in this diff or another one up simultaneously
I really want to land this. Just wanted to surface my concerns so you could address quickly
i think this turned out quite nicely.
Mar 16 2021
Mar 15 2021
yes please this has been driving me crazy
Mar 12 2021
This is relatively clear overall. My big concern is naming here. In particular there are a couple overlapping terms here that confuse dynamic collect and static list fan in.
Mar 11 2021
Mar 5 2021
Mar 4 2021
Nice. Would love this in the run list viewer too!
Feb 19 2021
screenshot looks good. some of those events are deprecated and we should consider not rendering them
Feb 18 2021
"My interpretation of the the feedback we got was that "data flow between reusable, logical components" is too abstract to convey useful information. I also think we should downplay reusability in our core messaging - in most cases, writing reusable solids is not the right pattern."
Feb 15 2021
Feb 9 2021
mixing await and yield is a bit odd. is that normative in python?
Feb 2 2021
did you consider process-level isolation?
Feb 1 2021
Did we ever consider breaking tags into its own column?
Jan 29 2021
Sent via Superhuman ( https://firstname.lastname@example.org )
definitely think we should keep prefix like @dgibson. grepability is good
Very much support getting rid of the registry. Thanks for doing this! Let's just try to mitigate risk as much as possible with a diff this large
Jan 27 2021
I meant code artifact, like "solid", "pipeline", "resource" etc
Agree with nearly all of sandy's and rex's feedback.
Jan 24 2021
Very excited to see this land. Will defer to dish on the deets of the js.
Jan 23 2021
adding @sandyryza here. I think this makes a lot of sense and I don't think having the events be left-to-right and the graphs right-to-left is a big problem but open to other's perspective
"I'm pretty resistant to directions that involve using type annotations for anything other than annotating the actual Python type that's expected somewhere. It's fairly abusive of a Python language feature, and it causes non-trivial trouble for anyone who's trying to use that language feature in the correct way."
We could also get clever and try to reuse input_defs and output_defs supporting a few different variants:
I'm concerned about too many breaking changes and too much thrash. But I think that the critical thing here would be coming up with a more condense syntax for inputs and outputs. Right now if we forced users to InputDefinition and OuptutDefinition for the dagster-type-only case the code explosion would be brutal.
Jan 22 2021
Yeah my first instinct is stress and terror given our past forays into magically commingling the python and dagster type system.
Jan 19 2021
Here's a thought:
Jan 14 2021
Jan 13 2021
can you display pipeline name in addition to schedule name?
excited to see this land. I will let @prha look at the lint ish as I have little context on that
could you throw up a screenshot?
Jan 12 2021
"hardcoded_resource_instances" is a pretty rough name since they aren't really hardcoded. they are not fixed in code. maybe "resource_instances_to_override" or something?
Seems good. Will let others do a detailed review!
Jan 8 2021
just doing q mgmt. any other alternative names?