dylo-runtime

dylo-runtime provides supporting code for the con crate, handling module building and loading on MacOS and Linux. End users shouldn't need to use this crate directly - it exists as a dependency of the con crate and crates generated by the dylo-runtime tool.

However, this is the right place to learn about environment variables that will impact the behavior of dylo-runtime:

• DYLO_TARGET_DIR: Set the build directory for hot-reloadable plugins. By default, plugins are built into $HOME/.dylo-mods/{mod-name} or %USERPROFILE%\.dylo-mods\{mod-name} on Windows.

• DYLO_BUILD: Set to "0" to disable automatic mod compilation. Defaults to "1". Set to "verbose" to have cargo inherit stdout/stderr, which will show progress messages and colors.

In production, you probably want DYLO_BUILD to be set to 0, as your mods should be pre-built, and put in the right place, next to the executable.

Warning Make sure to build your mods with the dylo-runtime/import-globals and impl features enabled, just like dylo-runtime would do.

See the rubicon docs for more details: essentially, your mods need to refer to the same process-local and thread-local variables that your main app does, or stuff like tokio etc. will break.

That is, if your Cargo workspace looks like this:

workspace/
  Cargo.toml
  mods/
    mod-markdown/
    mod-clap/
    con-markdown/
    con-clap/
  app/
    Cargo.toml
    src/lib.rs etc.

Then dylo-runtime expects a file hierarchy like this:

workspace/
  target/
    debug/
      app
      libmod_markdown.dylib
      libmod_clap.dylib

Except it doesn't actually need to be in target/debug/ of anywhere — this could all be in a container image under /app or whatever.

ABI Safety

dylo uses rubicon to ensure that the ABI of the module matches the ABI of the app they're being loaded into.

If you mess something up, you should get a detailed panic with colors and emojis explaining exactly what you got wrong.

Note that if you need crates like tokio, tracing, eyre, etc. you should use their patched versions, see the rubicon compatibility tracker.