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

[Campbell Barton]

On Fri, Feb 22, 2013 at 4:59 PM, Chad Fraleigh <chadf at triularity.org> wrote:
> 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").

The whole thing - server/client communication, authentication...
managing addons for multiple blender versions, addon dependancies?
support binary files? (so/dll's for eg), dealing with half
installed/corrupt addons on the client, locking so multiple blender
versions don't clobber eachother, getting devs to use tools to manage
it... writing tools to manage it.

All of this can be done - it just takes time & energy, and even once
thats done, I'm not certain it would be adopted by our existing devs.

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

Yep, we've considered that, its probably most straightforward to begin
with, even so we'd need to have a branch for stable addons so devs
could do improvements without all users getting WIP changes
immediately,

>
>> 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)?

My impression is addon devs work on their own scripts, and tend not to
maintain other peoples so much.
So when a developer looses interest their addons often stop being
properly maintained.

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

contrib addons are not distributed with blender releases. Im currently
happy with how this works out and dont think we need a more external
repo.

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

you assume right :)

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



-- 
- Campbell