- User Since
- Mar 20 2019, 8:23 PM (112 w, 2 d)
Fri, May 7
I think we can just remove it from all docs and examples and leave it as undeprecated since the cost of keeping it around is low
Wed, May 5
Tue, May 4
I'll let @alangenfeld accept, but I'm very supportive of this change and excited to see it land!
Fri, Apr 30
Actually duh that is in the daemon process rather than dagit.
I think this is potentially an exciting improvement (despite some initial hesitancy about the magic) and not just for testing. There are other benefits as well:
One last question on this one: what happens if someone passes a non-json serializable value in the dictionary that gets automatically coerced to JsonMetadataEntryData. Do we have a clear error message? A test of this would be good.
Thu, Apr 29
This looks great. A huge improvement. One minor thing is that I think we should add a union or marker interface identify all entry data classes for more concise documentation (probably some code wins too?).
Wed, Apr 28
Convo with Sandy on slack:
Chatted with sandy briefly and got to agreement. This content should eventually be massaged and resurfaced in a guide or post. I archived it here: https://docs.google.com/document/d/1B7fEOM8Ga03NbDwSu29LF7--JDri8JPGV1YBeE4rIIE/edit
Tue, Apr 27
No problem on the thrash. think I'm the one that started (or at least continued) the bikeshedding party! We should probably use the term "values" instead of "variables" in examples, tests, and docs, but I think this is good.
Cool. Agree with your reasoning on the _def suffix! Was just spitballing. Req'ing for q mgmt.
Yeah that name in particular I find very confusing. Config is the way that you specify how something is constructed, rather than the output of that construction process. It also makes it sound like a property or feature of the config system, rather than the other way around. I'm concerned about the reaction of "Oh a config resource. I guess this means the config system has a resource concept as well?"
Oh I misinterpreted/read. So you are proposing introducing a new class EventMetadata?
removing myself to reduce noise. please re-add once this is ready for review!
Given that we're introducing the short form and the assumption is that the long form will used way way less, I don't think that renaming the long form is worth the thrash.
Reflecting on this I think the major con of this approach is that the term "variable" (1) makes it feel like an integrated feature as opposed to a user-space feature that a user could easily implement on their own, (2) it occupies the term "variable" which could potentially be used for a feature in the future and (3) it could cause confusion with Airflow variables.
Mon, Apr 26
Yes effectively that with a little sugar and an approachable framing.
Not suggesting a reserved keyword. This is mostly about naming and norms. I think people are likely to understand intuitively what a variables_resource is used for and the config variant is harder to understand. This also allows the use of the variables resource without specifying a config schema.
This name is definitely a bit tough. If I wanted to get global variables into the pipeline make_config_resource wouldn't really lead me to it.
Fri, Apr 23
whats the plan with this?
seems like a good compromise
Thu, Apr 22
should be really straightforward to implement invokable on top of this
One other thing worth noting here is that since we are passing inputs directly and getting out outputs directly resource requirements from i/o managers should be ignored
I think it's a great direction and solves the problem quite elegantly.
Agree with alex that we should focus on direct solid execution only
I'd like to have a nice dagstermill example in the repo, and this was the best one. Other than that I support deleting.
Wed, Apr 21
great stuff. consider final comment but big improvement
that did it! thanks
This is a great overall. Just a few suggestions.
The preview link looks out-of-date?
Tue, Apr 20
Yes I think this is a good idea
Mon, Apr 19
This is a great strat.
per-offline discussion agree with decision that InputProps or similar doesn't clear the cost-benefit bar right now
One reason I like the named "InputProps" is that it felt additive, rather than the single source of truth for definitions. My concern here is that input defs would no longer be a single source of truth. The current state of things is definitely annoying so this is not a veto or anything. Just raising the concern.
We also need to determine the fate of the dagit "config nub" with this change. cc: @bengotow
Thu, Apr 15
minor changes but bouncing back to your queue
Super excited for this change. Big step forward. Thanks @cdecarolis for working through this. Will let others approve.
Apr 14 2021
I'd love to get this in for tmrw's release. Feel free to take stab at my proposed refactor or not. Your discretion.
Apr 13 2021
To be clear in vanilla solids you still have to raise these right?
Apr 12 2021
Apr 10 2021
Apr 4 2021
Mar 30 2021
Mar 25 2021
Mar 22 2021
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
Mar 19 2021
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