pluginmgr(3tcl)

✨ NAME ✨

Okay so first things first bestie: this is pluginmgr, and it lives in the Plugin management section of the manual — so if you saw pluginmgr(3tcl) floating around, that's literally her. And what does she do? Manage a plugin. That's the whole vibe. 💅

---

🎀 SYNOPSIS 🎀

package require Tcl 8.5 9
package require pluginmgr ?0.5?
::pluginmgr objectName ?option value...?
::pluginmgr::paths objectName name...
objectName method ?arg arg ...?
objectName clone
objectName configure
objectName configure option
objectName configure -option value...
objectName cget -option
objectName destroy
objectName do arg...
objectName interpreter
objectName plugin
objectName load string
objectName unload
objectName list
objectName path path
objectName paths

---

💖 DESCRIPTION 💖

So this package hands you commands and objects for the generic management of plugins — the kind that get loaded into an application. Very "build once, plug in forever" of it. 🧚

Here's the tea though: they did not go build yet another whole system just to find Tcl code. Nope. The whole thing sits on top of the regular package management system. Every plugin is treated as a package, and a simple package require is enough to locate it and load it, if it exists. Periodt.

The only time you'll need extra paths is when a plugin manager is part of a wrapped application and has to be able to search for plugins living outside that application. For exactly that situation, the package gives you a command to build a general set of such paths, based on names for the plugin manager and/or the application in question. 🫶

But the real main character move of this package is a generic framework that lets you easily declare:

1. How to translate a plugin name to the name of the package implementing it, and vice versa. 🔄
2. The list of commands a plugin has to provide as API — plus more complex checks, as code. 📋
3. The list of commands the plugin expects from the environment. 🌍

And that is what lets you easily generate plugin managers customized to particular types of plugins for an application. Obsessed, honestly.

⚠️ Super important, no cap: all plugin code is considered untrusted and will always be executed within a safe interpreter. The interpreter is enabled enough to let plugins load all the additional packages they may need. That's the balance. 💅

---

🌸 PUBLIC API 🌸

💫 PACKAGE COMMANDS 💫

::pluginmgr objectName ?option value...?

This creates a brand-new plugin manager object, with a Tcl command attached to it whose name is objectName. That object command is explained in full, juicy detail in the sections OBJECT COMMAND and OBJECT METHODS. 💖

The object command gets created under the current namespace if objectName is not fully qualified, and in the specified namespace otherwise. Simple as that.

The options and their values coming after the name of the object set the initial configuration of the manager object — i.e. they specify the applicable plugins and their API.

::pluginmgr::paths objectName name...

This utility command adds a set of paths to the specified object, based on the given names. It will search for:

1. The environment variable name_PLUGINS. Its contents get interpreted as a list of package paths, and the entries have to be separated by either : (unix) or ; (windows). The name will be converted to upper-case letters.
2. The registry entry "HKEY_LOCAL_MACHINE\SOFTWARE\name\PLUGINS". Its contents get interpreted as a list of package paths, entries separated by ;. This item is considered only when on Windows (tm). The casing of letters is not changed.
3. The registry entry "HKEY_CURRENT_USER\SOFTWARE\name\PLUGINS". Its contents get interpreted as a list of package paths, entries separated by ;. This item is considered only when on Windows (tm). The casing of letters is not changed.
4. The directory "~/.name/plugin".
5. The directory "~/.name/plugins". The casing of letters is not changed.

and add all the paths found that way to the list of package paths maintained by the object. 🎀

If name is namespaced, each item in the list will be repeated per prefix of name, with conversion of :-sequences into the proper separator — underscore for environment variables, backslash for registry entries, and / for directories. iykyk.

Examples, because seeing it hits different:

::pluginmgr::paths ::obj docidx

=> env  DOCIDX_PLUGINS
   reg  HKEY_LOCAL_MACHINE\SOFTWARE\docidx\PLUGINS
   reg  HKEY_CURRENT_USER\SOFTWARE\docidx\PLUGINS
   path ~/.docidx/plugins

::pluginmgr::paths ::obj doctools::idx

=> env  DOCTOOLS_PLUGINS
   env  DOCTOOLS_IDX_PLUGINS
   reg  HKEY_LOCAL_MACHINE\SOFTWARE\doctools\PLUGINS
   reg  HKEY_LOCAL_MACHINE\SOFTWARE\doctools\idx\PLUGINS
   reg  HKEY_CURRENT_USER\SOFTWARE\doctools\PLUGINS
   reg  HKEY_CURRENT_USER\SOFTWARE\doctools\idx\PLUGINS
   path ~/.doctools/plugin
   path ~/.doctools/idx/plugin

---

🦋 OBJECT COMMAND 🦋

Every command created by the command ::pluginmgr (see the section PACKAGE COMMANDS up there 👆) has the following general form, and you use it to invoke all sorts of operations on its plugin manager object.

objectName method ?arg arg ...?

The method method and its arg'uments decide the exact behavior of the command. See the section OBJECT METHODS for the detailed specs. 💅

---

👑 OBJECT METHODS 👑

objectName clone

This method creates a new plugin management object and returns the associated object command. The generated object is a clone of the object the method was invoked on, meaning the new object has the same configuration as the current one.

Now for the state part, because this is the cute bit: if the current object has a plugin loaded, then that plugin and all associated state is moved to the generated clone, and the current object is reset into the base state (no plugin loaded). So yeah — a configured plugin manager is literally also a factory for loaded plugins. Slay.

objectName configure

Called with no arguments at all, this method returns a list of all known options and their current values.

objectName configure option

Called with a single argument, this method behaves like the method cget and returns the value of the option specified by said argument. 🎀

objectName configure -option value...

Called with an even number of arguments — at least two, bestie — this method reconfigures the specified options of the object, setting them to the associated values.

The legal options are described in the section OBJECT CONFIGURATION. 📋

objectName cget -option

This method expects a legal configuration option as its argument and returns the current value of that option for the object the method was invoked on.

The legal configuration options are described in the section OBJECT CONFIGURATION. 👑

objectName destroy

This method destroys the object it is invoked for. Bye bestie. 💀

objectName do arg...

This method interprets its list of arguments as the words of a command and invokes that command in the execution context of the plugin. The result of the invoked command becomes the result of the method.

⚠️ The call will fail with an error if no valid plugin has been loaded into the manager object. So load something first, fr fr.

objectName interpreter

This method returns the handle of the safe interpreter the current plugin is loaded into. An empty string as the return value signals that the manager currently has no valid plugin loaded. 🙈

objectName plugin

This method returns the name of the plugin currently loaded. An empty string as the return value signals that the manager currently has no valid plugin loaded.

objectName load string

This method loads, validates, and initializes a named plugin into the manager object. The whole glow-up, start to finish. ✨

The algorithm to locate and load the plugin is:

1. If the string contains the path to an existing file, then this file is taken as the implementation of the plugin.
2. Otherwise the plugin name is translated into a package name via the value of the option -pattern, and then loaded through the regular package management.
3. The load fails.

The algorithm to validate and initialize the loaded code is:

1. If the option -api is non-empty, introspection commands are used to ascertain that the plugin provides the listed commands.
2. If the option -check is non-empty, the specified command prefix is called.
3. If either of the above fails, the candidate plugin is unloaded again.
4. Otherwise all the commands specified via the option -cmds are installed in the plugin.

A previously loaded plugin is discarded — but only if the new plugin was found and successfully validated and initialized. And ngl, there will be no interference between the old and new plugin, because both get put into separate safe interpreters. 🧚

objectName unload

This method unloads the currently loaded plugin and returns the empty string. The call is silently ignored if no plugin is loaded at all. No drama, no error.

objectName list

This method uses the contents of the option -pattern to find all packages which can be plugins under the purview of this manager object. It translates their names into plugin names and returns a list containing them. 🍓

objectName path path

This method adds the specified path to the list of additional package paths to look at when searching for a plugin. It returns the empty string.

Duplicate paths are ignored — each path is added only once. Paths are made absolute, but are not normalized. Keep that in mind, bestie.

objectName paths

This method returns a list containing all additional paths which have been added to the plugin manager object since its creation. 🌈

---

⭐ OBJECT CONFIGURATION ⭐

All plugin manager objects understand the following configuration options:

---

and okay we are SO not done here — the actual options list is coming right up in the next part, don't you dare close the terminal 💅🫶

• -pattern string — okay so bestie, this value is a glob pattern, and it has to contain exactly one '*'-operator. All packages whose names match this pattern are the plugins recognized by the manager object. And vice versa, the replacement of the '*'-operator with a plugin name will yield the name of the package implementing that plugin. This option has no default, except if option -name was set. It has to be set before attempting to load a plugin, either directly, or through option -name. 💅
• -api list — the value of this option is a list of command names, and any plugin loaded has to provide these commands. Names which are not fully qualified are considered to be rooted in the global namespace. If empty, no expectations are made on the plugin. The default value is the empty list. ✨
• -check cmdprefix — the value of this option is interpreted as a command prefix. Its purpose is to perform complex checks on a loaded plugin package to validate it, which go beyond a simple list of provided commands. It is called with the manager object command as the only argument and has to return a boolean value. A value of true will be interpreted to mean that the candidate plugin passed the test. The call will happen if and only if the candidate plugin already passed the basic API check specified through the option -api. The default value is the empty list, which causes the manager object to suppress the call and to assume the candidate plugin passes. 🦋
• -cmds dict — the value of this option is a dictionary. It specifies the commands which will be made available to the plugin (as keys), and the trusted commands in the environment which implement them (as values). The trusted commands will be executed in the interpreter specified by the option -cmdip. The default value is the empty dictionary. 🎀
• -cmdip ipspec — the value of this option is the path of the interpreter where the trusted commands given to the plugin will be executed in. The default is the empty string, referring to the current interpreter. 🌸
• -setup cmdprefix — the value of this option is interpreted as a command prefix. It is called whenever a new safe interpreter for a plugin has been created, but before a plugin is loaded. It is provided with the manager object command and the interpreter handle as its only arguments. Any return value will be ignored. Its purpose is to give a user of the plugin management the ability to define commands, packages, etc. a chosen plugin may need while being loaded. 👑

---

🐛 BUGS, IDEAS, FEEDBACK 🐛

Okay bestie, this document and the package it describes will undoubtedly contain bugs and other problems. Please report such in the category pluginmgr of the Tcllib Trackers at http://core.tcl.tk/tcllib/reportlist. Please also report any ideas for enhancements you may have for either package and/or documentation. We love a glow-up. 💖

When proposing code changes, please provide unified diffs, i.e. the output of diff -u. Fr fr.

Note further that attachments are strongly preferred over inlined patches. Attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar. 🫶

---

🔑 KEYWORDS 🔑

plugin management, plugin search

---

🏷️ CATEGORY 🏷️

Programming tools

---

📜 COPYRIGHT 📜

Copyright (c) 2005 Andreas Kupries <andreas_kupries@users.sourceforge.net>

---

Footer vibes: tcllib, version 0.5, page pluginmgr(3tcl). No date in the footer, just pure version energy. That's the whole page, bestie. Stay iconic. 💅✨