2024-01-30 Extensions Project

Extension Project


  • Campbell Barton
  • Dalai Felinto
  • Francesco Siddi (partly)

Recent changes

Updates since the previous meeting:

  • Development of extensions now happens in ‘main’ (no longer a separate repository).
  • New site-wide warning about being alpha.
  • Replace download button with install.
  • Aggregated json with all extensions types : extensions.blender.org/?format=json.
  • Separation between slugs (e.g., blender-kitsu) and id (e.g., blender_kitsu).
  • Support for non-add-ons extension types (both in Blender and more prominently on the site).
  • Use the TOML manifest as a source for extensions instead of bl_info.
  • New user interface in Blender.

Package and manifest file

Most of the meeting was about the final decisions that had to be made about the manifest file.

  • Settled on the name: “blender_manifest.toml”.
    • It is explanatory (no abbreviations).
    • It explains what the technology is (it is not just a random manifest file, but a Blender’s one).
    • It follows the pattern we use for the asset catalogs file (blender_…).
  • Content inside .zip, optionally inside a subfolder.
  • Mandatory values:
    • author
    • blender_version_min
    • description
    • id
    • license
    • name
    • schema_version
    • tagline
    • tags
    • type
    • version
  • Optional values:
    • homepage
    • copyright
    • blender_version_max


This is an example file, which will be used in the user documentation.

schema_version = "1.0.0"

# Example of manifest file for a Blender extension
# Change the values according to your extension
id = "my_example_extension"
version = "1.0.0"
name = "Test Extension"
tagline = "This is another extension."
description = "Where to access the add-on, basic usage."
# Supported types: "add-on", "asset-bundle", "keymap", "theme"
type = "add-on"

# Optional link to documentation, support, source files, etc
# homepage = "http://extensions.blender.org/add-ons/my-example-extension/"

# List defined by Blender and server, see: 
# https://docs.blender.org/manual/en/4.1/extensions/tags.html
tags = ["Modeling", "UV", "Motion Capture"]

blender_version_min = "4.1.0"
# Optional: maximum supported Blender version
# blender_version_max = "5.1.0"

author = [
  "Developer name <[email protected]>",
  # Also support paths starting with "./"
# License conforming to https://spdx.org/licenses/
# use "SPDX: prefix.
license = [
# Optional: required by some licenses.
# copyright = [
#   "2002-2024 Developer Name",
#   "1998 Company Name",
# ]

Fields breakdown

  • Which fields are optional:
    • Unless otherwise stated, all fields are required.
    • NOTE: Requiring but accepting empty values is a way to ensure developers are aware the fields exist and don’t ignore them.
    • copyright
    • blender_version_max
    • homepage
  • Which fields are case-insensitive:
    • id
    • copyright
    • tags (matches are case insenstive).
  • Which fields may not be empty:
    • id, *version*, name, type.
  • Copyright:
    • Year[-Year] Name.
  • Identifier (id):
    • Always lowercase, any uppercase warns (and converts to lowercase).
    • Needed to prevent collisions on case-insensitive filesystems.
    • Must comply to "my_extension_id".isidentifier().
  • Tags (tags):
    • Pre-defined list of possible tags.
    • Tags can be mixed case, use “title case” convention.
    • Can be expanded per-request, needs to be in sync with Blender and the server.
  • License:
    • Any license is supported as long as it is SPDX.
    • The server itself will be limited to free/open licenses.
  • Homepage:
    • Optional on the manifest
    • Server still requires a homepage
      • Pre-filled with either manifest or (when absent) the extension url (e.g., https://extensions.blender.org/add-ons/my-addon).
    • Documentation and Tracker urls are gone.
  • Open topic, build related values (globbing files, etc).
    • For now if we experiment with them they are optional.
    • The server will ignore non-documented values.
  • Unhandled topic, architectures… operating-system.

User Interface

The current design is to have all the interaction related to extensions in a single “Extensions” tab on the user preferences. There you can get/remove/update, besides enable/disable and set user preferences.


Wow this is amazing! Im glad you guys have what seems final design.

Im assuming asset libraries in File Paths menu in preferences will be moved in Extentions as well? Judging by the add-on enum

Id like to get in on beta testing whenever possible with my addons

1 Like

There are no plans to move asset libraries, since asset libraries can be used locally without extensions, extensions also aren’t suitable for large asset libraries.

Does this mean there will no longer be “Documentation” or “Report a Bug” buttons for add-ons?


That’s correct. Instead we will have a single URL button.

For the simple cases, the extension will use the page from the platform (e.g., http://extensions.blender.org/add-ons/blender-kitsu).

There, in the extension description, all the extra URLs can be provided.

The server can still have a special treatment for docs/issues/source URLs, and show it nicely in the extension description. That said, this is not information that need to be part of the TOML (or passed through the JSON).