# cp.plugins

This is a simple plugin manager.

It has a few core functions:

This function will load all enabled plugins in the specified 'parent' folders. For example:

local plugins = require("cp.plugins")
plugins.init("~/Library/Application Support/CommandPost/Plugins")

This will load all plugins in the current user's Library/Application Support/CommandPost/Plugins folder.

Once the plugins have been loaded, the module can be accessed by their ID via the getPluginModule(id) function. It will return the module returned by the plugin's init function. This can also be done via the default function for the library. Eg:

plugins("my.plugin.id").doSomething()

Plugins typically have two parts:

1. The plugin table, which defines details about the plugin, and
2. The module, or result, which could be anything, which is returned from the init function.

A plugin file should return a plugin table that allows the plugin to be initialised. The table will look something like this:

local module = {}

local module.init(otherPlugin)
    -- do stuff with otherPlugin here
end

local plugin = {
    id = "my.plugin.id",
    group = "foo",
    dependencies = {
        ["some.other.plugin"] = "otherPlugin",
    },
}

function plugin.init(dependencies)
   -- do stuff to initialise the module here
   module.init(dependencies.otherPlugin)
   return module
}

function plugin.postInit(dependencies)
   -- do stuff that will happen after all plugins have been initialised.
end

As you can see above, plugin module can have a few simple functions and properties. The key ones are:

This is a unique ID for the plugin. It is used to load the plugin externally, as well as to define dependencies between plugins.

This is the group ID for the plugin. This is used to group plugins visually in the Properties panel for Plugins.

This optional property can be specified for plugins which should never be disabled. This should only be set for plugins which will break the application if disabled.

This is a table with the list of other plugins that this plugin requires to be loaded prior to this plugin. Be careful of creating infinite loops of dependencies - we don't check for them currently!

It is defined like so:

plugin.dependencies = {
    "cp.plugins.myplugin",
    ["cp.plugins.otherplugin"] = "otherPlugin"
}

As you can see, there are two ways of declaring a dependency. The first is with just the plugin ID, the second has an alias.

These can be accessed in the `init` and `postInit` functions like so:

```lua
function plugin.init(dependencies)
   local myPlugin = dependencies["cp.plugins.myplugin"]
   local otherPlugin = dependencies.otherPlugin -- or dependencies["cp.plugins.otherplugin"]
end

A plugin will only have its init function called after its dependencies have successfully had their init functions called. Additionally, if a plugin has a postInit, all declared postInits for dependencies will have been called prior to the plugin's postInit function.

This function is basically required. It will be executed when the plugin is initialised. The dependencies parameter is a table containing the list of dependencies that the plugin defined via the dependencies property. The environment provides access to resources such as images, HTML files, or other lua modules that are bundled with the plugin. See Simple vs Complex Plugins below.

As you may have noted, there are two ways to specify a plugin is required. Either by simply specifying it as an 'array' item (the first example) or as a key/value (the second example). Doing the later allows you to specify an alias for the dependency, which can be used in the init(...) function, like so:

local plugin = {}

plugin.dependencies = {
    "cp.plugins.myplugin",
    ["cp.plugins.otherplugin"] = "otherplugin"
}

function plugin.init(dependencies)
    local myplugin = dependencies["cp.plugins.myplugin"]
    local otherplugin = dependencies.otherplugin

    -- do other stuff with the dependencies

    return myinstance
end

return plugin

There are two types of plugin structures supported. The Simple version is a single .lua file that matches the above format for plugin. The Complex version is a folder containing an init.lua file that matches the above format.

The key advantage of Complex Plugins is that the folder can contain other resources, such as images, HTML templates, or other .lua files - including 3rd-party libraries if desired. These can be accessed via two main mechanisms:

1. The second environment parameter in the init function. This is a cp.plugins.env table, which provides access to files and templates inside the plugin folder. See the documentation for details.
2. The standard require method will allow loading of *.lua files inside the plugin from the init.lua.

For example, if you have a file called foo.lua in your folder, it can be required like so:

local foo = require("foo")

You do not have to know anything about where the plugin folder is stored, or use the plugin ID. Just use the local file path within the plugin. If you have another file in a foo folder called bar.lua, it can be loaded via:

local fooBar = require("foo.bar")

These modules will not be accessible to other plugins or to the main application. They are only available to code inside the plugin.

• cp.plugins.env
• cp.plugins.plugin

Constants - Useful values which cannot be changed

• CACHE
• SETTINGS_DISABLED

Variables - Configurable values

• IDS

Functions - API calls offered directly by the extension

• addDependent
• disable
• enable
• getDependents
• getPlugin
• getPluginIds
• getPluginModule
• getPlugins
• init
• initPlugin
• initPlugins
• isDisabled
• loadComplexPlugin
• loadDependencies
• loadSimplePlugin
• postInitPlugin
• postInitPlugins
• scanDirectory
• watchPluginPaths