squashed into https://dagster.phacility.com/D6133

squashed into https://dagster.phacility.com/D6133

squashed into https://dagster.phacility.com/D6133

squashed into https://dagster.phacility.com/D6133

squashed into https://dagster.phacility.com/D6133

up

up

up

up

up

up

Very excited to see this land. Will defer to dish on the deets of the js.

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

• Instead of flipping, scroll the asset materialization grid to the right by default
• Fix React warnings in the useViewport component, some useCallback's missing

"As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first."

"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."

possibly relevant:

I like the variants you listed that involve overloading the input_defs arg on solid.  I think that kind of overloading is pretty Pythonic / expected. When reading that code, it's very difficult to misinterpret what's going on.

up

up

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.

rebase

rebase

rebase

Update

Add contributors channel

Improve test coverage line by line

requesting a few changes. next time, might be better to do this in a quip doc for faster iteration?

rebase

@schrockn those concerns make a lot of sense.

remove unused images

update last references of k8s -> kubernetes

Yeah my first instinct is stress and terror given our past forays into magically commingling the python and dagster type system.

It would be nice to have a better story for these named tuples. Unfortunately, it might require mucking around with metaclasses to support overriding init if we want to do runtime type checking.

others have more context on this than I

@schrockn do you have thoughts here? I think I would be OK with any of the options raised by @alangenfeld. I vaguely recall that you had some concerns about getting fancy with auto-creation/parameterization of types.

It would be nice to have a better story for these named tuples. Unfortunately, it might require mucking around with metaclasses to support overriding init if we want to do runtime type checking.

rebase