Plugin manifest¶
A plugin manifest declares a module's identity, its dependencies, where its binary is, and which SDK it was built against. It is the file the toolchain and the engine both read to decide what a module is.
One extension, *.nosplugin, covers both plugins and subsystems. A folder containing exactly one
.nosplugin is treated as a plugin target by the toolchain, which scans Module/ (or
MODULE_DIRS) recursively.
Minimal manifest¶
{
"info": {
"id": {
"name": "mycorp.myplugin",
"version": "0.1.0"
},
"display_name": "My Plugin",
"description": "",
"dependencies": []
},
"sdk_version": "41.0"
}
Complete example¶
Vulkan.nosplugin
{
"info": {
"id": {
"name": "nos.sys.vulkan",
"version": "8.0.0"
},
"display_name": "Vulkan Subsystem",
"description": "Graphics Subsystem for Nodos using Vulkan.",
"dependencies": [
{ "name": "nos.sys.shaderc", "version": "2.1" },
{ "name": "nos.sys.settings", "version": "3.0" },
{ "name": "nos.sys.device", "version": "2.0" },
{ "name": "nos.transfer", "version": "0.1" }
],
"category": "Graphics"
},
"defaults": [
"Types/Defaults.json"
],
"binary_path": "Binaries/nosSysVulkan",
"third_party_software": ["Config/Licenses.json"],
"sdk_version": "41.0",
"schema_version": "1.4-v1"
}
Fields¶
info¶
info.id.name— string, required- Globally unique package name. Dotted namespace convention:
<namespace>.<module>, e.g.nos.sys.vulkan. This is the name used bynodos installand in other modules'dependencies. info.id.version— string, required- Semantic version of this module. This is the version that gets published. Bump the major component on any API break.
info.display_name— string- Human-readable name shown in the editor.
info.description— string- Short description.
info.dependencies— array- Modules this one requires. Each entry is
{ "name": ..., "version": ... }. The version is a minimum within its minor line, matchingnodos installsemantics. Resolved by the toolchain at generation time and by the engine at load time — a module whose hard dependencies cannot be satisfied does not load. info.category— string- Category used to group the module in the editor.
Top level¶
binary_path— string- Path to the compiled binary, relative to the manifest, without a platform extension. The engine
appends
.dll,.soor.dylib. Omit for modules with no compiled code, such as shader-only node plugins. sdk_version— string, required- Plugin SDK version this module targets, e.g.
"41.0". Determines which SDK the toolchain fetches and generates a target against. This is what marks a manifest as belonging to the 1.4 line. schema_version— string- Manifest schema version, e.g.
"1.4-v1". defaults— array of strings- Paths to JSON files providing default pin values for the module's types.
custom_types— array of strings- Paths to
.fbsFlatBuffers schemas. The toolchain runsflatcover these and generates headers intoInclude/<PluginName>. ATypes/folder is picked up without listing it here. third_party_software— array of strings- Paths to JSON files declaring third-party licence information.
Plugin folder layout¶
mycorp.myplugin/
├── mycorp.myplugin.nosplugin
├── Binaries/ # build output; binary_path points here
├── Include/
│ └── mycorpMyplugin/ # public headers, including the plugin's API header
├── Nodes/ # *.nosnode definitions, auto-discovered
├── Source/ # C++ implementation; globbed recursively
├── Types/ # *.fbs schemas
├── Shaders/ # by convention
├── Tests/ # graph files run by `nodos test`
├── .nospub # optional; limits what `nodos publish` uploads
└── CMakeLists.txt # optional; additive to the generated target
Source/ is globbed recursively with CONFIGURE_DEPENDS, so adding a .cpp needs no build file
change.