is there a canonical solution to this?

I'm one of the developers of Sverchok and we are more frequently getting installation issues where people install the 2.79 version of Sverchok on Blender 2.8+. We maintain two different Sverchok codebases for Blender 2.79 and 2.8+, and they are massively, massively, different.

Is there anything simple we can stick in the __init__.py that will prevent the user from enabling the 2.79 version of the add-on in blender version 2.8.0 or above.


Blender 2.80 already protects against enabling incompatible add-ons. If the Blender version in the bl_info is too low, it will display a warning in the preferences. Blender will not run the register() function on these add-ons. However it does allow to tick the checkbox and the user may get the impression that it's properly enabled.

Warning in preferences

If you want to avoid that, you can check the Blender version and raise an exception in your __init__.py. This will prevent the checkbox from being enabled and the user gets an error message right away. I'm not sure if it will have the intended effect, since some users may not read or understand the error message.

bl_info = {
    "name": "Version Check Add-on",
    "author": "Robert Guetzkow",
    "version": (1, 0),
    "blender": (2, 79, 0),
    "location": "View3D > Sidebar > My own addon",
    "description": "Checks if the correct version of Blender is used",
    "warning": "",
    "wiki_url": "",
    "category": "3D View"}

import bpy

if bpy.app.version > (2, 79, 0):
    raise Exception("This add-on is incompatible with Blender versions newer than 2.79.\n"
                    "For Blender 2.8 please download the version from the following link:\n"
                    "[insert link here]")

class EXAMPLE_PT_panel(bpy.types.Panel):
    bl_label = "My own addon"
    bl_category = "Name of your tab"
    bl_space_type = "VIEW_3D"
    bl_region_type = "TOOLS"

    def draw(self, context):
        layout = self.layout
        layout.label("Congratulations, your Blender version is supported.")

classes = (EXAMPLE_PT_panel,)

def register():    
    for cls in classes:

def unregister():
    for cls in classes:

if __name__ == "__main__":
  • $\begingroup$ yep. lovely stuff - thank you. $\endgroup$
    – zeffii
    Oct 14 '19 at 13:26
  • $\begingroup$ @zeffii you're welcome. Although I'm not (yet) familiar with the add-on activation code in Blender, it may be an easy patch to disable the checkbox when the add-on is recognized to be incompatible. $\endgroup$
    – Robert Gützkow
    Oct 14 '19 at 13:30
  • $\begingroup$ we do a lot of stuff in __init__.py before register , raising an Exception is fine with me. $\endgroup$
    – zeffii
    Oct 14 '19 at 13:31
  • $\begingroup$ @zeffii ok. It would still make sense to discuss this with the devs though. I can't think of any reason why it should be possible to enable the checkbox when the add-on is incompatible, other than the code change would be unnecessarily complicated for this small change. $\endgroup$
    – Robert Gützkow
    Oct 14 '19 at 13:35
  • $\begingroup$ @zeffii You could also open the URL to the correct add-on version on Github using the webbrowser module. This may be not well received though, since it's very invasive behavior for an add-on. $\endgroup$
    – Robert Gützkow
    Oct 14 '19 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.