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

[Nathan Vegdahl]

A topic that has come up over on bf-committers is the possibility of
supporting multiple co-installed versions of the same addon, without it
showing up as a conflict in the addon browser.

Consider the following use-cases:

1. A Blender user makes heavy use of an external renderer. For their
professional work, they prefer to stick with an older tried-and-true stable
version, but for personal experimentation they want to play with the latest
bleeding-edge development version. They wish to install the addons for
both versions of the renderer, and enable different versions of the addon
depending on whether a project is personal or professional.

2. An animation studio is making their own custom changes to an officially
supported addon, but wish to have both the original supported version and
their own custom version available while their changes are still unstable
and untested.

I think a fairly straight-forward way to support this from the user
perspective is simply to distinguish addons based on the version number,
allowing the listing of multiple co-installed versions of an addon as long
as the version number is different. Maybe that's a bit naive, though. I'm
not entirely sure what back-end changes are needed to support this.

--Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130226/8f75d945/attachment.htm

[Jason van Gumster]

Nathan Vegdahl <cessen at cessen.com> wrote:

> A topic that has come up over on bf-committers is the possibility of
> supporting multiple co-installed versions of the same addon, without it
> showing up as a conflict in the addon browser.

A complication I see with this is in the event that the user actually enables
both (or more) versions of the add-on. Assuming that the add-on(s) make
additions/overrides to the UI in the form of panels, menus, and hotkeys,
there's no easy way to differentiate what UI element belongs to which version
of the add-on.

So perhaps I'm stating the obvious, but in order for this to work, a check
should be included to prevent multiple enabled instances of the add-on. The
question then becomes: how does that get implemented and enforced?

-Jason

[Nathan Vegdahl]

Hi Jason,
You raise an important point. On bf-committers I stated an assumption that
this would not be supported. But I don't think it necessarily needs to be
enforced.

The bottom line is that addon writers can enable or break different levels
of co-existence between multiple versions of their addon. A clever addon
writer could in fact make it possible to enable multiple versions of their
addon simultaneously. And, conversely, I imagine an addon writer could
write their addon in such a way that enabling even just one version breaks
when multiple versions are installed.

My intent is simply for this to be supported in Blender, and then it's up
to addon writers to write their addons in a way that is friendly to this.

--Nathan


On Tue, Feb 26, 2013 at 10:40 AM, Jason van Gumster <
jason at handturkeystudios.com> wrote:

>
> Nathan Vegdahl <cessen at cessen.com> wrote:
>
> > A topic that has come up over on bf-committers is the possibility of
> > supporting multiple co-installed versions of the same addon, without it
> > showing up as a conflict in the addon browser.
>
> A complication I see with this is in the event that the user actually
> enables
> both (or more) versions of the add-on. Assuming that the add-on(s) make
> additions/overrides to the UI in the form of panels, menus, and hotkeys,
> there's no easy way to differentiate what UI element belongs to which
> version
> of the add-on.
>
> So perhaps I'm stating the obvious, but in order for this to work, a check
> should be included to prevent multiple enabled instances of the add-on. The
> question then becomes: how does that get implemented and enforced?
>
> -Jason
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130226/d92081d0/attachment-0001.htm

[CoDEmanX]

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.



Am 26.02.2013 19:40, schrieb Jason van Gumster:
>
> Nathan Vegdahl <cessen at cessen.com> wrote:
>
>> A topic that has come up over on bf-committers is the possibility of
>> supporting multiple co-installed versions of the same addon, without it
>> showing up as a conflict in the addon browser.
>
> A complication I see with this is in the event that the user actually enables
> both (or more) versions of the add-on. Assuming that the add-on(s) make
> additions/overrides to the UI in the form of panels, menus, and hotkeys,
> there's no easy way to differentiate what UI element belongs to which version
> of the add-on.
>
> So perhaps I'm stating the obvious, but in order for this to work, a check
> should be included to prevent multiple enabled instances of the add-on. The
> question then becomes: how does that get implemented and enforced?
>
> -Jason
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>

[Asbjørn]

On 27.02.2013 13:05, CoDEmanX wrote:
> I don't see a sensible way to add multiple addon version support to
> Blender...

Well, concurrently I agree. But if you could have a dropdown in the
addon browser, so you could switch the active version, that could work.
It'd then deactivate version X and activate version Y.

Cheers
- Asbj?rn

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

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

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

[Domino Marama]

On 02/27/2013 02:05 PM, CoDEmanX wrote:
> maybe rename one of the two addons and add something like this to both?
>
>
It'd complicate matters for version control, and for preparing releases
- I want to make my life easier not harder :)

Also with that, it's not simple to identify the latest version as it
could be either the release or testing version depending on which a user
last updated. It also wouldn't cover situations where a user has a
version they modified for their own use, so there could potentially be
release, development, local development (+some old version that was
frozen for their production perhaps).

Currently I use a symlink in my scripts directory and just update that
to point to the version I want to use - this wouldn't be an option for
an alternate version of a script included with Blender though. Having
support for selecting different versions of particular scripts in
Blender would streamline things both in workflow and for a consistant
way to handle things for users. Being able to install scripts from
within Blender made things so much easier for supporting multiple
platforms, and I'd hate going back to having platform specific issues to
deal with.. Though maybe that cat is out of the bag now I've mentioned I
use symlinks on my setup.. Hopefully none of my users are reading this ;)

[Clemens Barth]

Dear Nathan.

I think that this is a very, very good proposition!

I have some colleagues, who also work with the /Atomic Blender addons/
[1] (import/export of PDB and XYZ files).
When there is a very new version from my side and my colleagues want to
use this version, it mostly ends
up in a Team Viewer session: I manually replace the Python files in the
main Blender directory via
overwriting the old version - work done in a shell, which my colleagues
cannot do due to a lack of shell
knowledge. All this is quite time consuming ... .
Note that an existing addon (from trunc and I think also from contrib)
cannot be replaced by manually installing
the same addon via the preferences (we tried a couple of times without
any success).

So, if Blender allows installing one and the same addon several times
and shows all different versions it would
help a lot: the user can then use the preferences and manually install a
new version of the addon himself. After,
he decides, which version he wants to use (only one version).

Regards,

Clemens.

[1] Atomic Blender:
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/PDB
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/XYZ



> A topic that has come up over on bf-committers is the possibility of
> supporting multiple co-installed versions of the same addon, without
> it showing up as a conflict in the addon browser.
>
> Consider the following use-cases:
>
> 1. A Blender user makes heavy use of an external renderer. For their
> professional work, they prefer to stick with an older tried-and-true
> stable version, but for personal experimentation they want to play
> with the latest bleeding-edge development version. They wish to
> install the addons for both versions of the renderer, and enable
> different versions of the addon depending on whether a project is
> personal or professional.
>
> 2. An animation studio is making their own custom changes to an
> officially supported addon, but wish to have both the original
> supported version and their own custom version available while their
> changes are still unstable and untested.
>
> I think a fairly straight-forward way to support this from the user
> perspective is simply to distinguish addons based on the version
> number, allowing the listing of multiple co-installed versions of an
> addon as long as the version number is different. Maybe that's a bit
> naive, though. I'm not entirely sure what back-end changes are needed
> to support this.
>
> --Nathan
>
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130226/c5e26235/attachment.htm

[Ryan Southall]

Hi.
I can't figure out if I'm doing something wrong in my script or there is a
bug in the vertex normal calculation.
I have a script that uses
Code:
mesh = obj.to_mesh(bpy.context.scene, True, 'PREVIEW', calc_tessface=False)
mesh.transform(obj.matrix_world)

to give me world data for an object obj. This correctly returns world
space face normals & position, and vertex position, but incorrect vertex
normals. I have to accept first any rotation of the object to get correct
vertex normals.
Am I doing something wrong? I'm on arch linux 64bit with a vanilla 2.66
install.
Cheers
Ryan

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130226/d4d696cc/attachment.htm

[Brecht Van Lommel]

On Tue, Feb 26, 2013 at 11:25 PM, Ryan Southall
<R.Southall at brighton.ac.uk> wrote:
> I have a script that uses
> Code:
> mesh = obj.to_mesh(bpy.context.scene, True, 'PREVIEW', calc_tessface=False)
> mesh.transform(obj.matrix_world)
>
> to give me world data for an object obj. This correctly returns world space
> face normals & position, and vertex position, but incorrect vertex normals.
> I have to accept first any rotation of the object to get correct vertex
> normals.

I think you have to call mesh.update() to recalculate the vertex
normals. This is not done on every operation for performance reasons.
The face normals are computed on the fly from vertex positions so
those would be up to date automatically.

Brecht.

[CoDEmanX]

Brecht is right, face normals update automatically, but vertex normals
don't. Here's some code for the proof (run it on an object which you
rotated):

import bpy
from bpy import context as C

me1=C.object.to_mesh(C.scene, True, 'PREVIEW', False)
me2=C.object.to_mesh(C.scene, True, 'PREVIEW', False)

me1.transform(C.object.matrix_world)

print("Normal updated?", me1.vertices[0].normal != me2.vertices[0].normal)
me1.update()
print("Normal updated?", me1.vertices[0].normal != me2.vertices[0].normal)



Am 27.02.2013 16:53, schrieb Brecht Van Lommel:
> On Tue, Feb 26, 2013 at 11:25 PM, Ryan Southall
> <R.Southall at brighton.ac.uk> wrote:
>> I have a script that uses
>> Code:
>> mesh = obj.to_mesh(bpy.context.scene, True, 'PREVIEW', calc_tessface=False)
>> mesh.transform(obj.matrix_world)
>>
>> to give me world data for an object obj. This correctly returns world space
>> face normals & position, and vertex position, but incorrect vertex normals.
>> I have to accept first any rotation of the object to get correct vertex
>> normals.
>
> I think you have to call mesh.update() to recalculate the vertex
> normals. This is not done on every operation for performance reasons.
> The face normals are computed on the fly from vertex positions so
> those would be up to date automatically.
>
> Brecht.
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>

[Ryan Southall]

Yep. That got it. Thanks both.
Ryan

CoDEmanX <codemanx at gmx.de> wrote:


Brecht is right, face normals update automatically, but vertex normals
don't. Here's some code for the proof (run it on an object which you
rotated):

import bpy
from bpy import context as C

me1=C.object.to_mesh(C.scene, True, 'PREVIEW', False)
me2=C.object.to_mesh(C.scene, True, 'PREVIEW', False)

me1.transform(C.object.matrix_world)

print("Normal updated?", me1.vertices[0].normal != me2.vertices[0].normal)
me1.update()
print("Normal updated?", me1.vertices[0].normal != me2.vertices[0].normal)



Am 27.02.2013 16:53, schrieb Brecht Van Lommel:
> On Tue, Feb 26, 2013 at 11:25 PM, Ryan Southall
> <R.Southall at brighton.ac.uk> wrote:
>> I have a script that uses
>> Code:
>> mesh = obj.to_mesh(bpy.context.scene, True, 'PREVIEW', calc_tessface=False)
>> mesh.transform(obj.matrix_world)
>>
>> to give me world data for an object obj. This correctly returns world space
>> face normals & position, and vertex position, but incorrect vertex normals.
>> I have to accept first any rotation of the object to get correct vertex
>> normals.
>
> I think you have to call mesh.update() to recalculate the vertex
> normals. This is not done on every operation for performance reasons.
> The face normals are computed on the fly from vertex positions so
> those would be up to date automatically.
>
> Brecht.
> _______________________________________________
> 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

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________

___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________

[Nathan Vegdahl]

Thanks for the support, Clemens! It's nice to know I'm not alone in
wanting this supported. :-)

--Nathan


On Tue, Feb 26, 2013 at 10:40 AM, Clemens Barth <barth at root-1.de> wrote:

> Dear Nathan.
>
> I think that this is a very, very good proposition!
>
> I have some colleagues, who also work with the *Atomic Blender addons*[1] (import/export of PDB and XYZ files).
> When there is a very new version from my side and my colleagues want to
> use this version, it mostly ends
> up in a Team Viewer session: I manually replace the Python files in the
> main Blender directory via
> overwriting the old version - work done in a shell, which my colleagues
> cannot do due to a lack of shell
> knowledge. All this is quite time consuming ... .
> Note that an existing addon (from trunc and I think also from contrib)
> cannot be replaced by manually installing
> the same addon via the preferences (we tried a couple of times without any
> success).
>
> So, if Blender allows installing one and the same addon several times and
> shows all different versions it would
> help a lot: the user can then use the preferences and manually install a
> new version of the addon himself. After,
> he decides, which version he wants to use (only one version).
>
> Regards,
>
> Clemens.
>
> [1] Atomic Blender:
>
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/PDB
>
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/XYZ
>
>
>
> A topic that has come up over on bf-committers is the possibility of
> supporting multiple co-installed versions of the same addon, without it
> showing up as a conflict in the addon browser.
>
> Consider the following use-cases:
>
> 1. A Blender user makes heavy use of an external renderer. For their
> professional work, they prefer to stick with an older tried-and-true stable
> version, but for personal experimentation they want to play with the latest
> bleeding-edge development version. They wish to install the addons for
> both versions of the renderer, and enable different versions of the addon
> depending on whether a project is personal or professional.
>
> 2. An animation studio is making their own custom changes to an
> officially supported addon, but wish to have both the original supported
> version and their own custom version available while their changes are
> still unstable and untested.
>
> I think a fairly straight-forward way to support this from the user
> perspective is simply to distinguish addons based on the version number,
> allowing the listing of multiple co-installed versions of an addon as long
> as the version number is different. Maybe that's a bit naive, though. I'm
> not entirely sure what back-end changes are needed to support this.
>
> --Nathan
>
>
> _______________________________________________
> Bf-python mailing listBf-python at blender.orghttp://lists.blender.org/mailman/listinfo/bf-python
>
>
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130226/3ef45ec8/attachment.htm

[Brendon Murphy]

On Wed, Feb 27, 2013 at 10:00 PM, <bf-python-request at blender.org> wrote:

> Send Bf-python mailing list submissions to
> bf-python at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.blender.org/mailman/listinfo/bf-python
> or, via email, send a message with subject or body 'help' to
> bf-python-request at blender.org
>
> You can reach the person managing the list at
> bf-python-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-python digest..."
>
>
> Today's Topics:
>
> 1. Re: Support listing of multiple versions of the same addon
> (Nathan Vegdahl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Feb 2013 15:22:59 -0800
> From: Nathan Vegdahl <cessen at cessen.com>
> Subject: Re: [Bf-python] Support listing of multiple versions of the
> same addon
> To: Blender Foundation Python list <bf-python at blender.org>
> Message-ID:
> <CAE91w2v=8f1dtkLyb6gfM=
> nK8owii0dj2S83RWpLb4BZ6hY-gQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks for the support, Clemens! It's nice to know I'm not alone in
> wanting this supported. :-)
>
> --Nathan
>
>
> On Tue, Feb 26, 2013 at 10:40 AM, Clemens Barth <barth at root-1.de> wrote:
>
> > Dear Nathan.
> >
> > I think that this is a very, very good proposition!
> >
> > I have some colleagues, who also work with the *Atomic Blender
> addons*[1] (import/export of PDB and XYZ files).
> > When there is a very new version from my side and my colleagues want to
> > use this version, it mostly ends
> > up in a Team Viewer session: I manually replace the Python files in the
> > main Blender directory via
> > overwriting the old version - work done in a shell, which my colleagues
> > cannot do due to a lack of shell
> > knowledge. All this is quite time consuming ... .
> > Note that an existing addon (from trunc and I think also from contrib)
> > cannot be replaced by manually installing
> > the same addon via the preferences (we tried a couple of times without
> any
> > success).
> >
> > So, if Blender allows installing one and the same addon several times and
> > shows all different versions it would
> > help a lot: the user can then use the preferences and manually install a
> > new version of the addon himself. After,
> > he decides, which version he wants to use (only one version).
> >
> > Regards,
> >
> > Clemens.
> >
> > [1] Atomic Blender:
> >
> >
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/PDB
> >
> >
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/XYZ
> >
> >
> >
> > A topic that has come up over on bf-committers is the possibility of
> > supporting multiple co-installed versions of the same addon, without it
> > showing up as a conflict in the addon browser.
> >
> > Consider the following use-cases:
> >
> > 1. A Blender user makes heavy use of an external renderer. For their
> > professional work, they prefer to stick with an older tried-and-true
> stable
> > version, but for personal experimentation they want to play with the
> latest
> > bleeding-edge development version. They wish to install the addons for
> > both versions of the renderer, and enable different versions of the addon
> > depending on whether a project is personal or professional.
> >
> > 2. An animation studio is making their own custom changes to an
> > officially supported addon, but wish to have both the original supported
> > version and their own custom version available while their changes are
> > still unstable and untested.
> >
> > I think a fairly straight-forward way to support this from the user
> > perspective is simply to distinguish addons based on the version number,
> > allowing the listing of multiple co-installed versions of an addon as
> long
> > as the version number is different. Maybe that's a bit naive, though.
> I'm
> > not entirely sure what back-end changes are needed to support this.
> >
> > --Nathan
> >
> >
>

Hi, I think this is not a good idea, you will/may get crashes if both
addons are enabled together. People will do that & it will cause issues
with classes & functions. I have done this many times myself.
If users need multiple versions of the same name, rename the classes &
addon with _1 if you must, This works & allows the forking of addons
,without core changes to Blenders Internal structure.
If the addons author is updating their addon in svn, there should be no
issue, the addon's latest version should match the latest Blender svn
revision. The addons users should then be directed to
http://builder.blender.org/ or http://www.graphicall.org/ to download the
latest revision of Blender. As the zipped files can be unpacked & run from
the desktop or user chosen location on most/all os this should be easy.
If in the case the user needs to update the addon for an installed version
of Blender, the addon author should provide exact instructions for the user
to locate the addon, delete the previous version & install the new version.
To do this manually is not difficult if good instructions are provided. go
here: "path to file" delete this: "file names" delete this too: "pycache"
copy paste in the new file/s: "put this here"
run blender.

This is just my opinion & may be flawed.
Thanks.
Brendon Murphy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130227/a2fb079a/attachment.htm

[Carsten Wartmann]

Am 26.02.2013 19:23, schrieb Nathan Vegdahl:
> A topic that has come up over on bf-committers is the possibility of
> supporting multiple co-installed versions of the same addon, without it
> showing up as a conflict in the addon browser.

How about copy the blender folder and then make a new shortcut to that
"version", there one can use different AddOns.

Of course there is the problem with the preferences stored into the user
folder. On Linux and with my own builds it stores them into the build
folder, so no problem here.

Carsten
--
Carsten Wartmann: Autor - Dozent - 3D - Grafik
Homepage: http://blenderbuch.de/
Das Blender-Buch: http://blenderbuch.de/redirect.html

[Nathan Vegdahl]

> How about copy the blender folder and then make a new shortcut to that
> "version", there one can use different AddOns.

Sure, this is a decent cludge for some of the use-cases for the time
being. My proposal is that we shouldn't need such a cludge, and that
users shouldn't be burdened with having to have multiple installs of
Blender just to install multiple versions of addons. And it gets
pretty ridiculous if you consider a user who wants even just a few
permutations of different addon's various versions.

--Nathan


On Thu, Feb 28, 2013 at 3:12 AM, Carsten Wartmann <cw at blenderbuch.de> wrote:
>
> Am 26.02.2013 19:23, schrieb Nathan Vegdahl:
> > A topic that has come up over on bf-committers is the possibility of
> > supporting multiple co-installed versions of the same addon, without it
> > showing up as a conflict in the addon browser.
>
> How about copy the blender folder and then make a new shortcut to that
> "version", there one can use different AddOns.
>
> Of course there is the problem with the preferences stored into the user
> folder. On Linux and with my own builds it stores them into the build
> folder, so no problem here.
>
> Carsten
> --
> Carsten Wartmann: Autor - Dozent - 3D - Grafik
> Homepage: http://blenderbuch.de/
> Das Blender-Buch: http://blenderbuch.de/redirect.html
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python

[Nathan Vegdahl]

I realize there are nay-sayers here who for some reason think this is
a bad idea, but there really are meaningful use cases for this, many
of which have already been outlined in this thread by myself, Clemens
Barth, and Domino Marama. This is a feature that is transparent and
will not hurt you if you don't use it, but does hurt you if you need
it and don't have it.

As I said earlier in this thread, enabling multiple versions of an
addon simultaneously is not part of the proposal. There are too many
complications with that, and this proposal does not intend to support
that unless by accident. Officially, enabling multiple version of the
same addon simultaneously would be unsupported. (I don't think it
needs to be _enforced_, however, but I'm open to ideas for how to do
that nicely.)

What I'm looking for in this thread is brainstorming how best to
support what _is_ in the proposal, which is simply to allow multiple
versions of the same addon to be installed and show up in the addon
browser.

I think distinguishing between addons based on the version string is a
useful way to do this, I think. By definition, identical version
numbers of an addon should mean identical addons, so I see no problem
in disallowing co-installation of same-versioned addons.

Clearly the back-end mechanics to make this work are going to be a
little trickier, however. For one thing, at the bare minimum
different versions of the same addon need to be installed in different
places or with different names or something. So some kind of standard
for that will be needed.

Ideas?

--Nathan

On Fri, Mar 1, 2013 at 10:21 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> How about copy the blender folder and then make a new shortcut to that
>> "version", there one can use different AddOns.
>
> Sure, this is a decent cludge for some of the use-cases for the time
> being. My proposal is that we shouldn't need such a cludge, and that
> users shouldn't be burdened with having to have multiple installs of
> Blender just to install multiple versions of addons. And it gets
> pretty ridiculous if you consider a user who wants even just a few
> permutations of different addon's various versions.
>
> --Nathan
>
>
> On Thu, Feb 28, 2013 at 3:12 AM, Carsten Wartmann <cw at blenderbuch.de> wrote:
>>
>> Am 26.02.2013 19:23, schrieb Nathan Vegdahl:
>> > A topic that has come up over on bf-committers is the possibility of
>> > supporting multiple co-installed versions of the same addon, without it
>> > showing up as a conflict in the addon browser.
>>
>> How about copy the blender folder and then make a new shortcut to that
>> "version", there one can use different AddOns.
>>
>> Of course there is the problem with the preferences stored into the user
>> folder. On Linux and with my own builds it stores them into the build
>> folder, so no problem here.
>>
>> Carsten
>> --
>> Carsten Wartmann: Autor - Dozent - 3D - Grafik
>> Homepage: http://blenderbuch.de/
>> Das Blender-Buch: http://blenderbuch.de/redirect.html
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-python

[Asbjørn]

On 01.03.2013 19:37, Nathan Vegdahl wrote:
> I realize there are nay-sayers here who for some reason think this is
> a bad idea, but there really are meaningful use cases for this, many
> of which have already been outlined in this thread by myself, Clemens
> Barth, and Domino Marama. This is a feature that is transparent and
> will not hurt you if you don't use it, but does hurt you if you need
> it and don't have it.

As an add-on developer I would find great use for such a functionality,
and I think our users could as well. It would be very nice to be able to
install both the unstable and the stable version, and be able to
effortlessly switch between them, for example to determine if an issue
is a regression.

> Clearly the back-end mechanics to make this work are going to be a
> little trickier, however. For one thing, at the bare minimum
> different versions of the same addon need to be installed in different
> places or with different names or something. So some kind of standard
> for that will be needed.

I think it would be best if the plugin has to announce (fex in the
script info block) that it supports "switching" versions. This would
avoid issues with weirdo scripts.

Cheers
- Asbj?rn

[Nathan Vegdahl]

Haven't gotten any proposals from anyone else, so I'll take a shot.

The key issue that needs to be addressed is that different versions of
the same addon need to be installable in different locations.
However, a sophisticated directory structure will be annoying for
people to manually abide by when e.g. copying addons into the addon
directory(s) by hand, or starting development on new addons.

Therefore, I propose that when installing an addon via Blender,
Blender will place addons into a directory structure that is based on
versions (see below), but that when Blender is searching for addons at
startup, it simply does a recursive directory search of the addon
directory(s). This helps keep things flexible. Users can drop/create
addons anywhere in the addons directory, and they will be picked up by
Blender. The directory scheme then is purely a tool for Blender
itself to install addons in unique locations.

For the directory structure that Blender creates when installing
addons, I propose the following:
addon_name/version_string/addon.py

Or for addons written as packages (such as rigify):
addon_name/version_string/addon/__init__.py (and other files)

This introduces a bit of redundancy, as the addon name will likely
appear twice in the path, but this keeps things nicely separated.

When removing addons, Blender can check for resulting empty
directories and remove them as well.

--Nathan


On Fri, Mar 1, 2013 at 10:37 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
> I realize there are nay-sayers here who for some reason think this is
> a bad idea, but there really are meaningful use cases for this, many
> of which have already been outlined in this thread by myself, Clemens
> Barth, and Domino Marama. This is a feature that is transparent and
> will not hurt you if you don't use it, but does hurt you if you need
> it and don't have it.
>
> As I said earlier in this thread, enabling multiple versions of an
> addon simultaneously is not part of the proposal. There are too many
> complications with that, and this proposal does not intend to support
> that unless by accident. Officially, enabling multiple version of the
> same addon simultaneously would be unsupported. (I don't think it
> needs to be _enforced_, however, but I'm open to ideas for how to do
> that nicely.)
>
> What I'm looking for in this thread is brainstorming how best to
> support what _is_ in the proposal, which is simply to allow multiple
> versions of the same addon to be installed and show up in the addon
> browser.
>
> I think distinguishing between addons based on the version string is a
> useful way to do this, I think. By definition, identical version
> numbers of an addon should mean identical addons, so I see no problem
> in disallowing co-installation of same-versioned addons.
>
> Clearly the back-end mechanics to make this work are going to be a
> little trickier, however. For one thing, at the bare minimum
> different versions of the same addon need to be installed in different
> places or with different names or something. So some kind of standard
> for that will be needed.
>
> Ideas?
>
> --Nathan
>
> On Fri, Mar 1, 2013 at 10:21 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>> How about copy the blender folder and then make a new shortcut to that
>>> "version", there one can use different AddOns.
>>
>> Sure, this is a decent cludge for some of the use-cases for the time
>> being. My proposal is that we shouldn't need such a cludge, and that
>> users shouldn't be burdened with having to have multiple installs of
>> Blender just to install multiple versions of addons. And it gets
>> pretty ridiculous if you consider a user who wants even just a few
>> permutations of different addon's various versions.
>>
>> --Nathan
>>
>>
>> On Thu, Feb 28, 2013 at 3:12 AM, Carsten Wartmann <cw at blenderbuch.de> wrote:
>>>
>>> Am 26.02.2013 19:23, schrieb Nathan Vegdahl:
>>> > A topic that has come up over on bf-committers is the possibility of
>>> > supporting multiple co-installed versions of the same addon, without it
>>> > showing up as a conflict in the addon browser.
>>>
>>> How about copy the blender folder and then make a new shortcut to that
>>> "version", there one can use different AddOns.
>>>
>>> Of course there is the problem with the preferences stored into the user
>>> folder. On Linux and with my own builds it stores them into the build
>>> folder, so no problem here.
>>>
>>> Carsten
>>> --
>>> Carsten Wartmann: Autor - Dozent - 3D - Grafik
>>> Homepage: http://blenderbuch.de/
>>> Das Blender-Buch: http://blenderbuch.de/redirect.html
>>> _______________________________________________
>>> Bf-python mailing list
>>> Bf-python at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-python