Jump to content

Getting Started Developing Add-Ons


Recommended Posts

Hello,

 

I am just getting started developing an add-on for Seeq. I have completed the foundations training and read the Seeq Knowledge Base. I have learned about add-ons and their extension mechanisms (AddOnTool, Frontend Plugins, Data Lab Functions).

 

I want to create an add-on similar (in structure and deployment, not in usage) to the Seeq-SysID add-on. I looked at the SysID add-on source and identified that it is using native python files and a Jupyter 'deployment notebook'. I am unable to recognize the add-on structure suggested here (no addon.json, no obvious AddOnTools, frontend plugins, or data lab functions).

I am having a hard time figuring out how to get started setting up my development environment. The add-on-development page in the Seeq knowledge base didn't quite have the information I need. I am also struggling to understand how this add-on is deployed on Seeq, since it is using native python files and does not appear to be packaged as a .addon as suggested here. Finally, I don't want to follow the method suggested here because I believe the approach may be limiting to the scope of the addon.

 

Here are my questions:

  1. The Seeq-SysID addon does not appear to follow the method of packaging that is suggested here. How is the Seeq-SysID addon packaged and deployed on Seeq? Does it require a user to install it locally before using it on Seeq?
  2. How is the Seeq-SysID addon able to use a purely native python backend with none of the add-on elements (AddOnTools, Frontend Plugins, and Data Lab Functions)?
  3. Can you guide me in getting started developing a similar (in structure and deployment, not in usage) addon?

 

Thank you so much for any help,

--Kin

Link to comment
Share on other sites

  • Seeq Team

Hey Kin, 

Great questions!

Seeq-SysID Add-on Packaging:

You're right. The Seeq-SysID Add-on in the Add-on Gallery predates the Add-on Manager and uses a different installation process. It gets  installed from the Data Lab terminal through a series of commands. This is acceptable for specific cases, but the newer, packaging approach offers more flexibility for future development.

 

The Add-on Tool Packaging Option:

For a more robust and maintainable Add-on, consider the packaging approach that you referenced (Add-on Development).  This method allows for flexibility in the types of Add-ons you are able to develop (AddOnTools, Frontend Plugins, and Data Lab Functions).  The .addon file is a zip file with your notebook and an addon.json file that describes the structure of Add-on.  Once your addon.json file is defined there is an helper build script to create the .addon file (Packaging)  However for simpler Add-on Tools, packaging is not necessarily required. 

Add-on Tool Development (Simple Approach):

If you prefer a simpler approach, Add-on Tools (Jupyter Notebooks run in Add-on Mode) are a good option and they don't require formal packaging (.addon file). Here's a helpful guide: How To Develop a Simple Interactive Add-on Tool

Publishing and Access Management:

Once your Add-on Tool functions as desired, you can publish it for wider use (assuming admin privileges). Here's the process:

  1. Development: Complete your code and ensure it meets expectations.
  2. Publishing (Admins): Use the User Tool Creator for publishing: Add-on Tool Administration and Development
  • The Add-on Manager automatically adopts the tool within an hour.
  • You can then manage user access through the Add-on Manager.
  1. Publishing (Non-Admins): Contact an admin to use the User Tool Creator for you.

Overall, the packaging approach is recommended for long-term maintainability and future expansion of your Add-on. However, the Add-on Tool option provides a simpler starting point if needed.

 

 

Link to comment
Share on other sites

10 minutes ago, John said:

The Add-on Tool Packaging Option:

For a more robust and maintainable Add-on, consider the packaging approach that you referenced (Add-on Development).  This method allows for flexibility in the types of Add-ons you are able to develop (AddOnTools, Frontend Plugins, and Data Lab Functions).  The .addon file is a zip file with your notebook and an addon.json file that describes the structure of Add-on.  Once your addon.json file is defined there is an helper build script to create the .addon file (Packaging)  However for simpler Add-on Tools, packaging is not necessarily required. 

Hi John,

Thank you for getting back to me! I want to learn more about the 'The Add-on Tool Packaging Option'. I've read the article, but I'm having a hard time getting started. A pointer to more reference material would be very helpful.

Do I just create .py files using whatever backend libraries I need, a frontend based on ipyvuetify (or similar), and a jupyter notebook that calls the frontend?

Thanks,

-- Kin

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...