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

Chad Fraleigh chadf at triularity.org
Fri Feb 22 06:59:06 CET 2013

On Mon, Feb 18, 2013 at 9:12 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Mon, Feb 18, 2013 at 7:38 PM, Chad Fraleigh <chadf at triularity.org> wrote:
>> This question probably has already be discussed, but are there any
>> plans to implement an addon deployment like mozilla applications
>> (firefox/thunderbird/seamonkey 2.x) uses where the client (blender)
>> can just browse a central http://addons.blender.org/ site (or
>> something) and with a click or two, install/upgrade what they want.
>> Then there would be few (or none) bundled by default. And if they are
>> bundled, they would act as defaults (i.e. only if that plugin hasn't
>> already been installed for the user, regardless of versions). Then
>> newer addons could be published without needing to align with the
>> blender release cycle.
>> Making sure already installed ones are compatible with potential
>> internal blender changes will still be an issue. But if addon
>> deployers (assuming more than just core blender developers could
>> maintain these addons) would keep what versions of blender that each
>> of their addons (by version) are compatible with. From that a single
>> metafile could be generate automatically/daily/whatever for blender to
>> download/check (with user consent) automatically when it detects a
>> different blender version installed.
>> Maybe  .bap  (Blender Addon Package) files (which are just zipfiles)? =)
>> And I assume python can be used [client side] to do all this, as-is,
>> and that resorting to trying a [much?] harder C implementation could
>> be avoided.
>> -Chad

> Gaia Clary has a working online addon browser, I'm not sure of the
> status right now though of if she intends to further develop it.

Is there a link to a demo somewhere that would give an idea of what
features it has?

> As I see it. the issue with this is we end up having to write our own
> package manager which is simple to begin with but gets complicated
> fast
> (consider existing extension repositories of mature applications -
> firefox and eclipse for example).

Are you specifically referring to the client side, server side
repository data (no UI), server side HTML repository browser
(read-only), and/or server side package CMS? The first two I expect
are simple enough, the third more effort, and the last being the
hardest (especially if updatable by "general users").

> So we need someone to write & maintain it, then buy-in from existing
> extension developers.

As a transition, the core addons could stay in subversion with maybe
just some metadata files added, but otherwise be maintained nearly the

> Since we already have a hard time maintaining existing addons in
> subversion, I'm not sure this would be a success at the moment.

Is this because there aren't enough core developers to maintain them
(including the contrib ones), or simply that they are "second class"
code that is mostly ignored until someone wants to improve one (or
something unexpectedly breaks due to an internal application change)?

If it is a developer resource problem, then if the contrib ones could
be more directly maintained by their contributors (instead of being
quasi-part of blender's code), in the long term it could reduce the
blender side maintenance (just like google doesn't "maintain"
publisher's individual android apps much beyond allowing them
add/update them on the google play site). If mainly for other reasons,
then I guess there isn't as much of a maintenance benefit beyond
offloading some contrib related codebase change requests.

Also, I'm guessing that the addons, as-is now, aren't generally [some
form of] unit test friendly to allow automated testing before each
release (assuming manually testing all of them is even done now).

I threw together a document (~14k text) of how I would envision (give
or take) a [remote] repository based addon/package system. While I'm
not sure how it compares to that addon browser that was already done,
I could post it (after I clean up the formatting a little) to see what
everyone thinks (that feels like doing some "lite reading" ;) ).


More information about the Bf-committers mailing list