Page MenuHomePhabricator

RFC: deprecate imports of lambda_solid from top level
Needs RevisionPublic

Authored by max on Oct 22 2020, 5:30 PM.

Details

Summary

This is what it might look like to implement https://github.com/dagster-io/dagster/discussions/3132

Test Plan

Unit

Diff Detail

Repository
R1 dagster
Branch
arcpatch-D4868
Lint
Lint OK
Unit
No Unit Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Oct 22 2020, 5:48 PM
Harbormaster failed remote builds in B20000: Diff 24267!
Harbormaster returned this revision to the author for changes because remote builds failed.Oct 22 2020, 7:32 PM
Harbormaster failed remote builds in B20017: Diff 24286!
Harbormaster returned this revision to the author for changes because remote builds failed.Oct 27 2020, 10:26 PM
Harbormaster failed remote builds in B20279: Diff 24605!
Harbormaster returned this revision to the author for changes because remote builds failed.Fri, Oct 30, 2:44 AM
Harbormaster failed remote builds in B20509: Diff 24865!
max requested review of this revision.Fri, Oct 30, 6:57 AM

After lambda_solid is removed publicly, we want to keep it around as an internal API? Why?

having done this work, i don't believe that lambda_solid makes even our tests any clearer

I do think this is an interesting case where overdoing it on "progressive disclosure of complexity" actually did active damage. The original idea was to be able to delay the introduction of the context object, at the expense of having an increase API surface. In this case it is pretty clear that that tradeoff was incorrect

schrockn requested changes to this revision.EditedSun, Nov 1, 2:28 PM

let's just change the warning to say it is being deleted. i doubt it is very broadly used.

Here's another idea. At 0.10.0 we could change it to

def lambda_solid(*args, **args):
   raise ApiDeletedException('Some text about using @solid instead')

That is *a lot* more informative than an import error. Now that I think about this would be an interesting generalized pattern for renames

This revision now requires changes to proceed.Sun, Nov 1, 2:28 PM