Plugin Development
This page covers the practical workflow for building a Tensormorph plugin, regardless of which extension point it targets - see Custom Tensor Adapters, Visualization API, Compute Backend API, and File Format API for what each extension point actually does.
Choosing WASM vs. native
Default to the sandboxed WASM path unless you have a concrete reason not to - direct CUDA/ROCm access, most commonly. WASM plugins are portable across every platform Tensormorph runs on without a separate build per OS/architecture, and they run under the same sandbox regardless of who wrote them, so there's no separate "is this plugin trusted" question to answer before loading one. The native path trades that portability and sandboxing for capabilities WASM can't provide, and requires a signature Tensormorph can verify.
Declaring your manifest
Your plugin's manifest declares which tm-plugin/1 traits it implements and which conditions activate it (a specific file extension, an architecture-detection signature, and so on) - Tensormorph reads this before running any of your code, so get the declaration right even before the implementation is complete; a plugin that declares narrowly and correctly is more useful to load than one that overclaims.
Testing
Test against both the cases your plugin should handle and the cases it should decline - for a ModelAdapter in particular, confirming the fallback adapter still handles a checkpoint your plugin correctly declines is as important as confirming a positive match works.
Related resources
- Extension API - the ABI, traits, and manifest model this workflow targets.
- Custom Tensor Adapters - the most common plugin type, with adapter-specific testing guidance.
- File Format API - the zero-copy bar a format-importer plugin should meet.