Code locations live under as separate subdirectories, each managed by . Shared code (base classes, utilities, sensors used by multiple locations) lives in .

dg_projects/
  <code_location_name>/
    pyproject.toml
    src/
      <code_location_name>/
        assets/
        sensors/
        ...
packages/
  ol-orchestrate-lib/
    ...

Use the tool to scaffold new code locations — not :

create-dagster <code_location_name>

Assets and sensors must be placed in the code location that owns them. Do not accidentally include an asset or sensor from one code location in another. When migrating or moving definitions, double-check / imports in each code location.

When migrating multiple code locations (e.g., from EC2/docker-compose to Kubernetes), do one code location at a time. The first location becomes the validated template. Never try to migrate all locations in a single PR.

The module inside is used as a base class by multiple code locations. It must remain in the library even if it looks unused from a single code location's perspective.

Static partitions with hardcoded values are the old approach. Prefer dynamic/time-based partitions when an up-to-date implementation already exists in another code location — copy that pattern rather than the older one.