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

[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
>