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

[Patrick Shirkey]

As a preliminary step could we have a script to verify the function calls
in each addon are still valid on a daily basis.

Just iterate across every function definition and validate against the
latest repo to check if the variables/structure of the calls are correct?

If any breakages are found send en email to the addon maintainers so they
have a headsup on what they need to fix.


Patrick



On Fri, February 22, 2013 4:59 pm, Chad Fraleigh 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").
>
>
>> 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.
>
>
>> 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" ;) ).
>
>
> -Chad
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


--
Patrick Shirkey
Boost Hardware Ltd