Plugin Naming Policies and Conventions
Intro/Teaser:
Plugins are a great way to extend DSS but sometimes it is difficult to tell which of your installed plugins are locally developed. Your installation of DSS comes with built-in plugins, but you can also add new plugins from the Plugin Store (here are the 2 ways to access), develop your own, or upload plugins from other developers. One way to keep all your ducks in a row is to apply a plugin naming convention. In fact, locally-developed plugins must follow the requirements described in this article.
Another benefit of following a naming convention is being able to identify the locally-developed plugins in your list of installed plugins. In addition, when you share your plugins, your colleagues will be able to understand the purpose of the plugin.
Note: Dataiku does not provide support for your locally-developed plugins. You are responsible for owning and maintaining the plugins you create.
What does this article contain?
This article describes plugin naming policies and recommendations. Naming is an important area of plugin development that is often overlooked. Dataiku DSS requires that plugin names and identifiers meet certain policies.
What are plugins?
A plugin is a package of reusable components that extends the functionality of DSS. When you make your own plugin, you are extending DSS. A plugin is made up of one or more components. A component is a GUI wrapper around custom code that exposes a Dataiku element such as a recipe, dataset, or web app.
What are some examples of plugins?
Plugins range from the very simple to the very complex. For example, plugins can be used to create a connector to read or write data to databases or connect to external APIs. Some examples are connecting with Salesforce data, or get weather forecast by location. You can find more plugins in the plugin store. The possibilities are limitless!
Why should I create plugins?
Plugins turn custom logic into components that can be used by anyone, giving less technical users the ability to collaborate and technical users the ability to standardize the way data is processed. Plugins can easily be shared by the community of users in an organization and even shared across organizations. Since most plugins are open source, anyone can view the underlying code and make contributions to it or adapt it.
Where can I find the code for the public plugins?
You can find the code for some but not all of the public plugins in GitHub (link).
Dss_public_plugins_github
Plugin naming
The plugin summary displays information about the plugin and its components. You can edit the display name and identifier for the plugin in the Edit tab.
You can also edit the component display name and component identifier in the Edit tab. Adding a description is a good idea because it documents the reason why you created the component and lets others understand its usefulness and purpose.
Plugin Naming Policies
A naming error happens when the name of the plugin, or any of its components, labels, or tags, does not meet plugin naming policies. Luckily, you can avoid these errors by following the plugin naming policies below. Most of the policies are required while a few are recommended. (Future: These rules are automatically checked by the plugin dev kit.)
Policy | Guidelines | Example |
Plugin display name and description | Avoid "plugin" or "custom" in the display name English noun or verb | 
|
Plugin identifier | Lowercase Use a dash “-” between words English language Do not use “plugin” or “custom” in the name of your plugin (i.e., custom-discriminant-analysis-plugin) | 
|
Component display name and description | Avoid "dataset", “plugin”, “custom”, or "recipe" in the component’s display name. Recommended: Short, descriptive labels that are grammatically correct. The component’s label displays in menus. | 
|
Component identifier | Lowercase Use a dash “-” between words English language Follow a consistent naming convention for all components. Do not invert the word order or exclude words. | 
|
Dataset identifier | DSS prefixes the dataset name with the name of the plugin. This is because DSS uses the component name as the fully qualified identifier. Avoid "dataset" or "custom" in the name of a dataset. Recommended: Use a noun to describe what the dataset displays, e.g., “raas” (Reports as a Service). | 
|
Recipe identifier | DSS prefixes the recipe name with the name of the plugin. This is because DSS uses the component name as the fully qualified identifier. Avoid "recipe" or "custom" in the name of a dataset. Recommended: Use a noun to describe the recipe or a verb to represent the recipe’s action. For example, in the "my-geocoder" plugin, a recipe that computes distance might be named, "my-geocoder-compute-distance". | 
|
Tags | Create and apply common tags. Do use generic tags such as, "API", "Open Data", "Productivity", and "Machine Learning". Avoid tags that are only used once. You may have a Fpoezy API plugin but a Fpoezy tag would not be useful since it's very likely that no other plugin will use this tag. | 
|
Plugin.json description
Code section | Details |
“Id”: “starter-plugins”, | The plugin id |
“Version”: “0.0.1”, | The version of the plugin |
“Meta”: { | Meta section |
“Label”: “Starter plugins”, | The plugin label |
“Description”: “”, | A short description of the plugin |
“Author”: “admin”, | Author of the plugin |
“Icon”: “icon-time”, | Icons from FontAwesome 3.1 |
“supportLevel”: | Whether or not the plugin is officially support by Dataiku |
“licenseInfo”: “Apache Software License”, | License provided by Apache Software |
“url”: | |
“tags”: |
How can I get started if I am new to plugins?
If you are new to plugins, you can get started by reading the latest documentation, completing step-by-step tutorials, and by visiting the Plugin store. From DSS, you can find the plugins by selecting Plugins from the administration menu:
Tip: One of the golden rules of plugins is to never use “import dataiku” in a library. With few exceptions, plugins do not depend on Dataiku unless it is an administrative plugin.