[Bf-committers] Rigify addon causes error, error, error,....

Nathan Vegdahl cessen at cessen.com
Tue Feb 26 19:24:27 CET 2013


Started a thread on bf-python about supporting multiple versions of the
same addon.

--Nathan


On Tue, Feb 26, 2013 at 9:55 AM, Nathan Vegdahl <cessen at cessen.com> wrote:

> >> Consider, for example, someone having two different
> >> versions of an external renderer installed, and they want to be able
> >> to use either/or in different projects (maybe one is more stable, but
> >> the other has more features).  I think there are meaningful use-cases
> >> outside of Rigify and the current situation.
> >
> > Agree, did you check on adding support for this?
> > if you wanted some help investigating ways to implement we could
> > continue discussion on bf-python.
>
> Sounds good.  And yeah, I'd be happy to attempt to tackle this after
> some discussion. :-)
>
> >> This is a use-case that should be better supported anyway, IMHO.
> >
> > Not sure how we would better support this - you can install an addon
> > from a zipfile, that parts fairly straightforward.
>
> I meant better supporting multiple different co-installed versions of
> an addon, as per my example of external renderers.
>
> > Whats inconvenient about maintaining an addon in svn?
>
> The situation that just came up is a good example: doing contract work
> on the addon during pre-release freeze.  It puts me in the position of
> having to choose between two bad options: committing significant
> changes during pre-release freeze, or doing major work without the
> safety (and documentation) of incremental commits.  Having a separate
> development repo (as I'm doing on github now) is a good way around
> this, though.
>
> Also, collaborating with others who are also doing significant
> development work on it.  Emailing patches back and forth isn't so
> nice, and you lose good commit logs that way.  DVCS makes this much
> nicer.  Again, using github or similar for unstable development works
> well to resolve this.  It's easy for people to branch and share work.
> In short, by hosting with DVCS, I get the benefits of DVCS.
>
> Finally, addons are still very poorly supported in the Blender bug
> tracker, with one mega-issue assigned to each.  Granted, this is not
> related to SVN per se.  But I've been annoyed by this for quite some
> time, and I'm _very_ keen to skirt around it until it is addressed.
> By hosting somewhere else I can point people to the tracker there (in
> this case on github) and I then have proper bug/issue/todo tracking
> for Rigify.
>
> > So if you can keep whats in trunk stable, maintained and update fixes
> > for release, this works, I just want to avoid fragmentation.
>
> I don't think that will be a problem.  I'll consider the Rigify in SVN
> the official supported stable version, and I'll backport bug fixes
> etc.
>
> --Nathan
>
>
> On Mon, Feb 25, 2013 at 2:36 PM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
> > On Tue, Feb 26, 2013 at 8:29 AM, Nathan Vegdahl <cessen at cessen.com>
> wrote:
> >>> Would prefer addon devs don't do this, some do already but it means we
> >>> can't be sure the addon in SVN is really the latest one, have to
> >>> contact devs before release to make sure we pull the latest version
> >>> in, and it won't be tested as much (or not and have older addons in
> >>> which miss features/fixes),
> >>
> >> While I understand the inconvenience this can pose, there is already
> >> too much inconvenience for me the other way around.
> >
> > Whats inconvenient about maintaining an addon in svn?
> >
> >> So for the time
> >> being, at least, I'm going to do primary development of Rigify on
> >> github (http://github.com/cessen/rigify), and merge stable changes
> >> during the appropriate BCon stages.  If the development model for
> >> addons included with Blender changes at some point, I'll reconsider.
> >> But I don't think that model necessarily needs to change.
> >
> > Don't blame you, I've been using git for development too (then moving
> > into svn when ready).
> >
> > So if you can keep whats in trunk stable, maintained and update fixes
> > for release, this works, I just want to avoid fragmentation.
> >
> >> I treat (and want to treat) Rigify as an independent project, and
> >> would really prefer a less centralized development model for it, and
> >> inclusion as an officially supported addon hinders both those things
> >> by design.  So this seems like a decent compromise: it lets me develop
> >> it independently as needed/wanted, but it can still be included as an
> >> official addon for those who want it to be so.  We can think of the
> >> github repo as something like a development branch.
> >
> > Ok, as a dev branch I see where your coming from, I still worry a bit
> > that changes wont be tested as well in our development builds.
> >
> >> I would also be perfectly happy for Rigify to not be included as an
> >> official addon, but I think there may be others that would object to
> >> that.  For example, there was a certain someone that argued in favor
> >> of its inclusion after Sintel. ;-)
> >
> > It's a shame if we can't provide users good tools by default (even
> > though they need to be enabled).
> > If rigify is fairly small and kept working with current blender
> > releases, I don't see why not include it.
> >
> >>> users who want to test latest version need
> >>> to manually grab it. - just becomes a hassle IMHO, ...makes conflicts
> >>> more likely too.
> >>
> >> This is a use-case that should be better supported anyway, IMHO.
> >
> > Not sure how we would better support this - you can install an addon
> > from a zipfile, that parts fairly straightforward.
> > The hassle is mostly that users need to know what to search for in the
> > first place, trust the script isn't malicious, check the version
> > matches their blender and manually update it from the authors web
> > site.
> >
> >> Obviously if two conflicting versions of an addon are enabled
> >> simultaneously, we can't expect that to work.  But simply having two
> >> different versions of an addon present... not sure why that needs be
> >> an issue.
> >
> > Not sure what your getting at here, it shouldn't be an issue, I'm
> > quite sure it can be added.
> >
> >> Consider, for example, someone having two different
> >> versions of an external renderer installed, and they want to be able
> >> to use either/or in different projects (maybe one is more stable, but
> >> the other has more features).  I think there are meaningful use-cases
> >> outside of Rigify and the current situation.
> >
> > Agree, did you check on adding support for this?
> > if you wanted some help investigating ways to implement we could
> > continue discussion on bf-python.
> >
> >> --Nathan
> >
> > --
> > - Campbell
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list