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

I'll let @alangenfeld accept, but I'm very supportive of this change and excited to see it land!

Actually duh that is in the daemon process rather than dagit.

Re: th

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.

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?).

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

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.

@sandyryza @yuhan What do you think of this approach?

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.

whats the plan with this?

seems like a good compromise

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.

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?

Yes I think this is a good idea

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

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.

up

up

up

I'd love to get this in for tmrw's release. Feel free to take stab at my proposed refactor or not. Your discretion.

To be clear in vanilla solids you still have to raise these right?

Very exciting.

lgtm. thanks!

From https://github.com/dagster-io/dagster/issues/3319

up

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

Having both feels very painful. Why can't they be consolidated?

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

q mgmt

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.

makes sense to me

yes please this has been driving me crazy

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.