As more people and organizations depend on Dagster, we think it’s important to be as explicit as possible about which Dagster APIs are public and which are private. Over the next few weeks we’re going to be incrementally renaming our informally private modules (all submodules of

dagster

) so that they are formally private. Users should target all

dagster

imports to the top-level

dagster

module:

# CORRECT
from dagster import op

# INCORRECT
from dagster.core.definitions.decorators import op

Renaming starts in our most recent release (

0.14.15

) with the rename of

dagster.check

>

dagster._check

. We hope this change will not affect the vast majority of users, since our public API has long been informally defined as the top-level

dagster

module. However, for users who are using private APIs or otherwise importing from

dagster

submodules, we have made some temporary accommodations. There’s a shim in place that will prevent our module renames from breaking runtime-- imports of old module names are dynamically resolved to their new locations (so

import dagster.check

is equivalent to

import dagster._check

as far as runtime is concerned). However, all submodule imports will now trigger linter warnings-- either because you are importing a formally private module (e.g.

dagster._check

) or because you are importing from a module name invisible to static analyzers (e.g.

dagster.check

). Please reach out in #dagster-support if this transition causes you any other problem!