[Bf-python] Support listing of multiple versions of the same addon

[CoDEmanX]

forgot to mention:

you need to edit scripts/modules/bpy/ops.py to make this work:

         if hasattr(context, "scene"):
             scene = context.scene
             if scene:  # None in background mode
                 scene.update()
             else:
                 import bpy
                 for scene in bpy.data.scenes:
                     scene.update()

or use the the actual function instead:

import addon_utils
addon_utils.disable("name_of_other_addon")


Am 27.02.2013 15:05, schrieb CoDEmanX:
> maybe rename one of the two addons and add something like this to both?
>
>
> def register():
>       bpy.ops.wm.addon_disable(module=name_of_other_addon)
>       # ...
>
> you wouldn't have to disable the other addon first, just enable the one
> you are currently interested in.
>
>
> Am 27.02.2013 13:41, schrieb Domino Marama:
>> On 02/27/2013 12:05 PM, CoDEmanX wrote:
>>> I don't see a sensible way to add multiple addon version support to
>>> Blender...
>>>
>>> Addon writers should write proper scripts - using PointerProperties to
>>> group their custom props. Then one could simply change PointerProp names
>>> and solve name property name conflicts.
>>>
>>> Renaming the script file (or if it's a module, then the folder) solves
>>> the multiple addon warning, but there are still a lot of name conflicts
>>> - especially class-names and operator bl_idnames. Solving these
>>> conflicts by hand is a lot of work, but how could this be avoided?
>>>
>>> I mean, how should Blender handle such cases? Wouldn't really helpful if
>>> it renamed classes and operators, as your script would call the wrong
>>> ops afterwards. Dynamic registration of ops inside of an addon is
>>> possible (could checkfor existing op with hasattr), but the only way i
>>> know to call such dynamic ops dynamically seems to be evil eval().
>>>
>>> http://www.blender.org/documentation/blender_python_api_2_66_release/info_overview.html#dynamic-defined-classes-advanced
>>>
>>> Well, I would eventually solve name conflicts by hand if i really needed
>>> an older version of an addon running simultanously.
>> I don't think running them simultaneously is the issue. For complex
>> scripts, there's often development and release (to testers for example)
>> in between Blender versions. So for bundled scripts, being able to have
>> the official Blender release and a development version of a script and
>> easily switch between them is useful. I'd find this very handy to switch
>> back to a release version to do end user support and my local
>> development versions for hacking on for example.
>>
>> In my case, both the release and development scripts aren't part of
>> Blender, so having the ability for users to switch between the version
>> they use for production and the testing version wouldn't be solved by a
>> simple "user scripts > blender scripts" option, which would probably
>> resolve some of the production use cases mentioned in this thread.
>>
>> Comparison testing is another area where it's handy to be able to switch
>> versions easily to confirm script rewrites produce comparable results to
>> the original.
>>
>>
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-python
>>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>