Commenting out body of functions seems unnecessary. Thrashes commit history (will all blame to you) and a refactor might be missed.

up

I'd be more open to making the tutorials available to dagit. I just want to keep dagster core as lean as possible.

I'm not convinced that this is what we want. A simpler solution would seem to be to have a separate repo for examples that is up-to-date with the latest public version. Implementing a tutorial downloader in the dagster core seems very odd to me.

Just feels a bit wrong to force people to deploy the tutorial the world over

Is there prior art in other systems here? I'm a little wary of putting this in core. How about making a separate installable dagster-tutorial module?

respin tests

Issue https://github.com/dagster-io/dagster/issues/2156

inconsistency of DagsterInvalidDefinitionError versus DagsterInvariantViolationError is unfortunate. however I think that we need a pretty substantial refactor of both the dagster and config type resolution codepath and would not like to embark on that in the next 30 mins

cool

good call on tests

Please include better summary but lgtm

rebase

abandoning in favor of https://dagster.phacility.com/D2009

rebase

up

up

@alangenfeld do you think we should change the airline_demo to be the verbose variant as well

looks great. merge away

q mgmt

The issue with an overwrite strategy is now the library could be counting on the mapping existing and then the user has blown it away and can do so at any time.

removing alex and max for now to avoid noise for now.

confirmed no new indentation warnings

up

no worries

My only other feedback would be that it would be great to vertically scroll to the node that is currently executing when you single click on it in the table of contents

let's sleep on it and I think @themissinghlink wanted to stew on it a bit

So I think a reasonable resolution to "undo" the selection of *foo*: If you double click again it toggles back to "*"

Great! Please heed final comments, especially on the first sentence (some of @max 's feedback was unaddressed) Great job! Fun to see this documented

spin tests

This was thrown up as an alternative/basis of discussion on https://dagster.phacility.com/D1996

Here's an example of what it would look like by using dagster types only in InputDefinitions and OutputDefinitions, and unmapped python types only in type annotations:

The advantage of moving this out is that it is quite "presumptuous" for a library to claim a fundamental type and map it to the dagster type. It could cause some quite magical behavior. Imagine a user who wants to use mypy but then they forget to use an InputDefinition or OutputDefinition with their specialized dagster types. The system would magically coerce it to the library's dagster type.

You definitely don't have to do this. You only do this *if* you want to be able to annotate your solids with the *python* type and have dagster associate the dagster type with it.

upmessage

up

looks good

Looking nice. Thanks for doing this.

feedback; next step is to switch to code literal includes

feedback

upmessage

q mgmt. good call @max

almost there. thanks for working through this!

rebase

Including the folks who I believe are responsible for breaking API changes this time around. @themissinghlink @nate if you have some api changes that require migration guide here you go

upmessage

upmessage

upmessage

up

up

This is pretty slick. A few product things:

up