- User Since
- Mar 20 2019, 8:23 PM (47 w, 6 d)
Commenting out body of functions seems unnecessary. Thrashes commit history (will all blame to you) and a refactor might be missed.
I'd be more open to making the tutorials available to dagit. I just want to keep dagster core as lean as possible.
Mon, Feb 17
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?
Thu, Feb 13
Wed, Feb 12
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
good call on tests
Please include better summary but lgtm
abandoning in favor of https://dagster.phacility.com/D2009
@alangenfeld do you think we should change the airline_demo to be the verbose variant as well
looks great. merge away
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
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
Tue, Feb 11
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.
Looking nice. Thanks for doing this.
feedback; next step is to switch to code literal includes
q mgmt. good call @max
almost there. thanks for working through this!
This is pretty slick. A few product things: