Starting with Blender 4.5, the developers fundamentally changed the approach to developing Blender add-ons. Now – Extensions, rather than Add-ons. The old add-on format still works correctly, and if you don’t intend to publish your add-ons in the official Blender Extensions library, you don’t need to change anything. However, if you want your add-ons to be supported by Blender in the future, it’s a good idea to make some changes now. One such improvement is the creation of a manifest file.
.toml file on Patreon
Each Blender add-on must now include a manifest file.
This is a simple text file containing summary information about the add-on. The manifest file specifies the data we previously specified in the bl_info structure in our add-on’s __init__.py file. The main purpose of this file is to transfer this reference information from the add-on’s main file into a separate file.
After you create the manifest file and fill it, you can delete the outdated “bl_info” structure in the __init__.py file.
Let’s create the manifest file.
The file name must be “blender_manifest” and the extension must be “toml.”
Create a blender_manifest.toml file in our add-on directory. It should later be included in the .zip archive with the add-on distribution.
Edit it as follows.
First, fill in the required fields:
The specification format version shoudl be first.
|
1 |
schema_version = "1.0.0" |
Next, we specify the add-on ID. Previously, the add-on ID was the name of its distribution, but now we can specify it manually.
|
1 |
id = "my_best_addon" |
Specify the add-on version. Previously, we specified the version as a tuple, for example, (1, 3, 3), but now it’s a text value, but we still need to follow the delimited format.
|
1 |
version = "1.3.3" |
The add-on name.
|
1 |
name = "My Best Add-on" |
Tagline – a brief description of the add-on. This is what we previously specified in the “description” field of “bl_info”.
|
1 |
tagline = "My add-on can do many interesting things" |
Information about yourself, the add-on developer. This should be in the format “name – contact email address”, or only name.
|
1 |
maintainer = "John Smith <john_smith@mail.com>" |
The type is always “add-on”. This indicates that this is an add-on. The second possible value, “theme,” is used when developing Blender themes.
|
1 |
type = "add-on" |
The minimum Blender version for which the add-on is intended. Also in numeric format with a period.
|
1 |
blender_version_min = "4.5.0" |
This specifies the add-on’s distribution license. You can specify your own license, but the correct license is the GPL. Therefore, it should always be specified like this:
|
1 2 3 |
license = [ "SPDX:GPL-3.0-or-later", ] |
Next, you can specify several more optional fields.
Tags. This is what we previously specified in the “category” field of “bl_info”. However, we can now specify multiple values at once.
|
1 |
tags = ["Material", "Render"] |
Full list of possible tags: 3D View, Add Curve, Add Mesh, Animation, Bake, Camera, Compositing, Development, Game Engine, Geometry Nodes, Grease Pencil, Import-Export, Lighting, Material, Modeling, Mesh, Node, Object, Paint, Pipeline, Physics, Render, Rigging, Scene, Sculpt, Sequencer, System, Text Editor, Tracking, User Interface, UV.
Specifies the highest possible Blender version for your add-on. It is assumed that your add-on no longer works with the Blender version specified in this field.
|
1 |
blender_version_max = "5.1.0" |
Link to your website or page where users can leave feedback or report bugs.
|
1 |
website = "https://my_addon_site" |
Specifies the platforms. For example, if your add-on only works on Windows and MacOs.
|
1 |
platforms = ["windows-x64", "macos-arm64"] |
Full list of possible platform values: windows-x64, windows-arm64, macos-x64, macos-arm64, linux-x64.
Permissions. These need to be specified if your add-on accesses additional devices on the user’s computer, for example – a camera.
|
1 2 3 |
[permissions] files = "Import/export non-blender format files from/to disk" clipboard = "Copy and paste to clipboard" |
The list of available devices: files, network, clipboard, camera, microphone.
Permissions must be specified for each device on a separate line with a brief description of the actions required.
These are not all the fields that can be included in your add-on’s manifest file. However, these are usually sufficient for 90% of all add-ons.
You may need additional fields if, for example, your addon uses third-party Python Wheels modules, requires certain files to be excluded when building the distribution, or, conversely, requires the inclusion of certain third-party additional files in the distribution. In standard cases, the fields listed above are sufficient in most cese.