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

[Campbell Barton]

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