← ClaudeAtlas

bl-info-migrationlisted

Migrate a legacy bl_info-format add-on to the Extensions Platform. Three concrete steps, before-and-after diff, dual-format pattern for backward compatibility, and answers to "is bl_info still supported?" Targets Blender 5.2 LTS.
TMHSDigital/Blender-Developer-Tools · ★ 13 · API & Backend · score 66
Install: claude install-skill TMHSDigital/Blender-Developer-Tools
# bl_info Migration to the Extensions Platform ## Trigger Use this skill when the user: - Has an existing add-on with a `bl_info = {...}` dictionary at the top of `__init__.py` - Wants to publish to extensions.blender.org or distribute as a `.zip` for the Extensions Platform - Asks "is bl_info dead?" or "do I have to migrate?" - Sees a deprecation warning at install time about legacy add-ons - Mentions `blender_manifest.toml`, "Install legacy Add-on", or "the new extension system" ## Is bl_info still supported? Yes, with caveats. - **In 5.1 stable**: `bl_info` is supported as a fallback for legacy add-ons. The Edit > Preferences > Add-ons panel still has "Install legacy Add-on" and recognizes `bl_info` dicts. - **For the Extensions Platform** (extensions.blender.org and the new add-ons UI): you need a `blender_manifest.toml`. `bl_info` is ignored. - **Dual format** is officially recognized: ship a `blender_manifest.toml` and keep the `bl_info` dict. The platform reads the manifest; legacy installers read `bl_info`. Both code paths work without conditional logic. The Blender Foundation's stated direction is that the Extensions Platform is the future and `bl_info`-only add-ons will degrade in discoverability over time, but they are not announcing a removal date. ## The three migration steps A migration from a `bl_info`-only add-on to the Extensions Platform takes three small mechanical changes. ### Step 1: Generate `blender_manifest.toml` Create a new file `blender_m