The following are best practices to follow when developing and packaging Add-ons.
Naming
There are four factions that should be considered when naming an Add-on.
Choose a unique Add-on identifier. This is a string that identifies your Add-on. It should be a reverse domain name, which means that it should start with the top-level domain (e.g., com, edu, org) and then be followed by the name of your company or organization, followed by the name of your Add-on. For example, if your company is called Seeq and your Add-on is called Example, your Add-on identifier would be com.seeq.addon.example.
Include the version number in the file name. The version number is a string that indicates the version of your Add-on. It should be specified as major.minor.patch, where major is the major version number, minor is the minor version number, and patch is the patch version number. For example, if your Add-on is currently in version 1.0.0, the version number in the file name would be 1.0.0.
Use the .addon extension. The .addon extension is the standard extension for Add-on files.
Use a consistent naming convention for all of your Add-on files. This will make it easier to keep track of your Add-ons and to find them when you need them.
Here is an example of a correctly named Add-on file:
com.seeq.addon.example-1.0.0.addon
Python Packages
When developing Python AddOnTool and DataLabFunctions elements, try to use the versions of libraries that are already in the image if available instead of pip installing a different specific version. You can see what’s already available by running PYTHONUSERBASE=/usr/local pip list in the Data Lab terminal. Following this best practice reduces the storage used and the amount of time it takes to install an Add-on.
