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

Campbell Barton ideasman42 at gmail.com
Mon Feb 18 10:08:55 CET 2013


On Mon, Feb 18, 2013 at 5:47 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
> Fair enough.
>
> Rigify is a bit unique among the addons, though, in that it is
> designed to be extensible via additional rig types.  And this is
> coming up here, where the version of Rigify in the official repo and
> the version on their local machines with custom extensions conflict.
> For this use-case, it's starting to feel like Rigify being in the
> official repo and included in official builds is actually a drawback
> rather than a benefit.  Right now we're getting around it by deleting
> the official repo version after every build, but that's pretty tedious
> and isn't scalable.

I'd guess there are multiple ways around this, and none should require
moving rigify to an external repo.

Are you modifying existing rigs or just adding new ones?

> Is there some way that we could rework addon loading such that local
> versions of addons (e.g. in .config/blender/x.x/scripts/addons)
> override and take precedence over official repo versions?  That way it
> is easy to have local versions of addons.  With a lot of addons that
> might seem pointless, but with Rigify it's actually an important
> use-case.

Yep, having local rigs makes sense and theres nothing really
complicated about it, just use blender api to get the user-path, then
python can load modules from that.

eg.
user_rig_path = bpy.utils.user_resource('SCRIPTS',
os.path.join("presets", "rigify"), create=True)

That path could be added to sys.path, though having all rigs in the
global module namespace might be a problem, so you could use pythons
`imp` module  to load them directly.

http://docs.python.org/dev/library/imp.html

> --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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell


More information about the Bf-committers mailing list