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

[Nathan Vegdahl]

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

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.

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. ;-)

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

--Nathan


On Sun, Feb 17, 2013 at 7:24 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Mon, Feb 18, 2013 at 4:58 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> Thanks for the fix Irie!
>>
>>> Anyway, I don't understand why you did such big changes in Bcon4...
>>
>> Fair enough.  It seemed like the best option of bad options.  I'm
>> currently working with a studio to improve Rigify for their pipeline,
>> but I have a limited amount of time to be on-site working with them.
>> Given that Rigify is an addon, and not part of Blender proper, I felt
>> it was worth it for the sake of properly documenting the changes and
>> milestones instead of having a mega-commit at the end.
>>
>> There's also a complicating factor, which is that they're working with
>> SVN blender, so every time they update, it wipes out any local Rigify
>> changes.
>>
>> All-in-all, perhaps not the best choice on my part, but it wasn't on a whim.
>>
>> In any case, I'll avoid this in the future.  Perhaps I ought to
>> maintain a parallel git repo somewhere for publishing out-of-sync
>> changes.
>
> 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), users who want to test latest version need
> to manually grab it. - just becomes a hassle IMHO, ...makes conflicts
> more likely too.
>
> Best just try avoid this situation again, if an addon is well
> maintained we shouldn't be finding its broken right before release.
>
> Of course if you wanted to make a git repo to work on some
> improvements during the week of the release, then pull the changes
> back into svn right after and continue development in SVN, thats
> different.
>
>> --Nathan
>>
>>
>> On Sat, Feb 16, 2013 at 7:51 PM, IRIE Shinsuke <irieshinsuke at yahoo.co.jp> wrote:
>>> Hi Nathan,
>>>
>>> Your recent commit (r4286) introduced a bug in poll() of the new
>>> "Rigify Dev Tools".  It causes an error every time UI is updated:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/irie/build/blender2.6/cmake/bin/2.65/scripts/addons/rigify/ui.py", line 206, in poll
>>>     return obj.mode == 'EDIT_ARMATURE'
>>> NameError: global name 'obj' is not defined
>>>
>>>
>>> The following patch fixes it:
>>>
>>> Index: release/scripts/addons/rigify/ui.py
>>> ===================================================================
>>> --- release/scripts/addons/rigify/ui.py (revision 4288)
>>> +++ release/scripts/addons/rigify/ui.py (working copy)
>>> @@ -203,7 +203,7 @@
>>>
>>>      @classmethod
>>>      def poll(cls, context):
>>> -        return obj.mode == 'EDIT_ARMATURE'
>>> +        return context.mode == 'EDIT_ARMATURE'
>>>
>>>      def draw(self, context):
>>>          r = self.layout.row()
>>>
>>>
>>> Anyway, I don't understand why you did such big changes in Bcon4...
>>>
>>> Thanks,
>>>
>>> --
>>> IRIE Shinsuke
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers