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

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