Package structure

Each DipDup project consists of a YAML config and a Python package of a specific structure. It could be placed anywhere, but needs to be importable. The package name is defined in the config file.

To generate all necessary directories and files according to config run the init command. You should run it every time you significantly change the config file.

The structure of the resulting package is the following:

There are also a bunch files in the root directory: .ignore files, PEP 561 marker, etc. Usually, you won't need to modify them.

ABIs and typeclasses

DipDup uses contract type information to generate Pydantic models to work with strictly typed data. We call these models typeclasses. Modules in the types directory are generated automatically from contract ABIs and JSONSchemas during init. You can modify them manually, but usually won't need to. Under the hood, the process is roughly the following:

• Contract ABIs are fetched from public sources or provided by the user.
• DipDup converts these ABIs to intermediate JSONSchemas.
• JSONSchemas converted to Pydantic models with datamodel-code-generator.

This approach allows working with complex contract types with nested structures and polymorphic variants.

Nested packages

Callbacks can be grouped into packages to organize the project structure. Add one or multiple dots to the callback name to define nested packages:

package: dipdup_indexer
hooks:
  backup.restore:
    callback: backup.on_restore

After running the init command, you'll get the following directory tree (shortened for brevity)

dipdup_indexer
├── hooks
│   ├── backup
│   │   └── on_restore.py
└── sql
    └── backup
        └── on_restore

Handler callbacks can be grouped the same way. Note, that callback name still needs to be a valid Python module path: only lowercase letters, underscores, and dots.