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

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