cheshire-cat-ai/plugins-backend

The backend of The Cheshire Cat plugin directory

plugins-backend's Issues

Analytics endpoint for plot

Could be useful to have an analytics endpoint to get some data and optionally a plot.
Here is the code to make a plot out of analytics.json

import pandas as pd
import plotly.express as px

json = pd.read_json("analytics.json", typ="series")

df = pd.DataFrame({
    "plugin": json.index.values,
    "downloads": json.values,
})

df = df.sort_values("downloads", ascending=True)
df["plugin"] = df["plugin"].map(lambda p: p.split("/")[-1])

px.bar(df, y="plugin", x="downloads") # could be saved as file or sent as binary/base64/whatever

Plugin zip cache: Try to download latest release before cloning

We are giving community a recommended way of creating a plugin, with this template that handles releases creating a ready made zip to download via Github public api.

Since method Endpoints.download_plugin_zip is already dealing with the creation of the zip, covering all non-template use cases, I propose to:

• take away this logic from core and rely on this service, to avoid duplicates
• check in Endpoints.download_plugin_zip if there is a release zip via Github public api (as done here)
• If no release is available, proceeds to clone the repo and create the zip as it already does

Maybe @valentimarco is interested at working on this (also @nicola-corbellini )

Better organization of the repo

• Rename the repo (proposal: plugins-backend)
• Create a backend folder and move all the files in there
• Create a frontend folder
• Create Dockerfile for the node frontend
• Align docker-compose.yml
• #9

Create a download counter

We can count single plugin total downloads.

Create a file logging system

ATM all the logs and debug are printed server side and are hard to extract and analyzed. We must create a more robust logging system for the registry.

Plugins sorting criteria

Cat admin shows plugins from the registry in two use cases:

• list plugins (no query)
• search (query is present)

How do we sort them?

Add Analytics data to the plugin object in endpoints

When we cache the plugin data (once a day) we have to add analytics.json data to the plugins' object

`/download` endpoint could use plugin's github URL as id

Since we are sure github repos' URLs are unique, I suggest using them as plugin id to get the .zip file from the /download endpoint

{
  "plugin_url": "https://github.com/..."
}

Enhance OpenAPI for Swagger and Redoc

• Logo
• Title
• Version
• Link

Decoupling the 'plugins' Endpoint from the In-Memory Cache System

Currently, the /plugins endpoint serves as the main controller for the cache system. This presents an issue with pagination, as making an initial paginated call results in an incomplete cached list.

To address this, we need to decouple the caching functionality from the specific endpoint. Additionally, some code refactoring is required to utilize only the cache retrieval function and the validity-check mechanism, triggering cache invalidation if the predetermined time interval has passed.

Tags endpoint doesn't seems to comma split tags

It should comma split tags, actually it doesn't.

Validate the JSON with an action on main push/merge

In order to avoid breaking JSON we have to validate the format of the list with a GitHub action.

Ending slash `/` in plugin repo link makes the registry crash

A plugin submission in which the repo url was ending with a / made the registry give 500 Internal Server Error
For sure we can enforce no ending slash in plugins repo in file plugins.json, but a final slash should not cause such a problem.

Implement stringent validation for individual plugin.json fields

Currently, the fields from various plugin.json files are all taken and included in the response of the different endpoints. This behavior, besides being risky, also leaves room for unintended errors on the part of developers.

We need to devise a method to validate the fields of the various plugins and only display those that are valid. Moreover, we should also consider returning only the plugins that have all the necessary minimal fields (name, description, url, author, tags, thumb, and version).

A mechanism should also be designed to notify any validation errors, perhaps by saving and making a log available through a designated endpoint. In this regard, we could also provide an endpoint to assist plugin authors in automatically validating their plugin.json files through actions (e.g., /validate or /validation).

Improve the readability of the file readme.md

Currently, the readme file is the sole source of knowledge regarding the project's endpoints. Therefore, a more elegant and clear way of organizing and displaying the endpoints along with their respective parameters needs to be found.