For our dagster assets we separate the logic of generating an asset from the dagster setup, so our assets will often look like:

@asset
def some_asset(context, other_asset):
  return our_lib.build_some_asset

but what we've noticed is that when we "Reload Definitions" our code in the business logic modules do not reload. Is this expected?

Hi Ben, Can you clarify exactly what you’re not seeing/expecting to see or create a minimal repro? One subtlety with “Reload Definitions” is that you shouldn’t even need to do it for new runs to reflect the result of business logic changes. That’s because new runs are going to launch in new processes, and these processes will load the code as it is on disk at the time the process is launched. What “Reload Definitions” does is update the state of the UI with changes you’ve made to your definitions.

interesting. we're finding that when we change something in our "business logic code" which is separate from our definitions code we have to shut down and restart for those code changes to be read. we're using docker compose locally with a code location, dagit, and daemon because it mirrors our k8s setup. we're mounting our code into the container as a volume. I'll see if i can isolate this behavior with a small repo at some point

Hmm I’m not a docker expert-- but is your definitions code included in the same mounted volume as the external lib/business logic?

yeah, they're side by side in same volume... src/pipelines src/pipelines_lib

one question to investigate is if “Reload Definitions” works at all-- like if you load, add a new asset to

Definitions

, and then “Reload Definitions” does the new asset show up?

hm. it doesn't reload when just adding an asset either. hmmm. not what i expected

I see, yeah that means something is happening at the level of your docker volume mounting. I just tested locally with a Docker container with a mounted volume containing defs and confirmed that reloading works as expected.

hey sean, sorry for the month long delay. 😰 we haven't managed to resolve this issue, but we're working around it easily enough.