[Bf-committers] PyAPI breakage and possible solutions

[Campbell Barton]

I'm not really interested in mailing list discussion on this topic, We
can agree addons for release must be stable.
Further, the script module owners can come to some consensus on the matter.

Which raises the topic... who are the module owner? :(
no script reference except for UI:
http://wiki.blender.org/index.php/User:DingTo/ModuleOwners-New

>From memory Brendon Murphy, Luca Bonavita and myself, Please correct
me if I'm wrong!

We can meet on IRC and decide if any changes are needed.

On Wed, Jun 16, 2010 at 4:10 PM, Daniel Salazar - 3Developer.com
<zanqdo at gmail.com> wrote:
>  One important thing to consider is the needed ability to separate
> Blender release cycles and addons update cycles, we propose a
> third-party addon repository hosted at graphicall because of that
> reason. Script maintainers could push updates without the need for
> people to download a new blender version. This is specially important
> for people who do not use unofficial builds
>
> cheers
>
> Daniel Salazar
> www.3developer.com
>
>
>
> On Wed, Jun 16, 2010 at 8:02 AM, mindrones <mindrones at gmail.com> wrote:
>> Hello,
>>
>> sorry for the long mail, there is some stuff that came up in irc that
>> I'd like we discuss here.
>>
>> Introduction
>> =====================================================
>>
>> There has been some discussion in #blenderpython about what to do with
>> "broken" scripts in bf-extensions svn: basically someone isn't
>> comfortable including scripts in the category "Broken".
>>
>> There's been some argument about the fact that people use Graphicall
>> builds with scripts bundled in, and this has been my exact proposition
>> when I first proposed bf-extensions workflow (tracker -> svn contrib ->
>> svn trunk).
>> I believe that having Graphicall distributing builds with embedded
>> contrib scripts is cool because people can test and report (and BTW,
>> Dingto added a "Report Bug" button to the addons panel so now it should
>> be easy to have feedback from users).
>>
>> But, there is some feeling that for this same reason we should provide
>> un-broken scripts. I don't think so. Graphicall is cool, but if it takes
>> scripts from bf-extensions it depends on the work being done in
>> bf-extensions, not the opposite.
>>
>> I don't think that we can maintain bf-extensions as it was a Release
>> each given day :)
>>
>> It might happen that an API change breaks a scripts or two and Campbell
>> already fixes scripts when he changes the API, but he confirms he
>> usually doesn't check contrib so some script might slip, it happens.
>>
>> Also, script developers can disappear at any time, even if their script
>> is in trunk. So if a script remains unmaintained for a long time we
>> should remove it, if it stays there broken for a reasonable time (means
>> days or a couple of weeks) IMO it can stay. It is also a good motivation
>> to fix it.
>>
>> Meta-Androcto also talked about "moving contrib scripts in Graphicall"
>> (which isn't very clear statement indeed) but I don't think this is
>> desirable, especially if the development will happen outside of a public
>> svn.
>>
>>
>> I propose here 2 solutions for 2 problems:
>> - how to solve broken scripts stuff
>> - how to have contrib scripts in blender
>>
>>
>> BROKEN SCRIPTS PROBLEM
>> =====================================================
>>
>> Two usual cases:
>>
>> A) We enable the addon (we don't install it)
>>
>>    To do this in the bl_addon_info dict we can add a "status" key that
>> could be = 'WORKING' or 'BROKEN'
>>
>>    Based on that, we do somthing similar to this mockup:
>>    http://www.pasteall.org/pic/show.php?id=4003
>>    Like this, when we enable an addon it is evident it is broken.
>>
>>
>> B) We install the script so that next times it is already enabled.
>>
>>    If after a commit an installed script becomes broken, again we could
>> use the "status" key in the bl_addon_info dict to:
>>     - disable the script (unregistering it?), and
>>     - alert the user with a popup
>>
>> If this approach is ok, we could even think about put this info in the
>> startup panel, but it's not important now.
>>
>>
>> CONTRIB SCRIPTS PROBLEM
>> =====================================================
>>
>> Currently this folder
>> https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/
>> is fetched into blender/release/scripts/addons.
>>
>> We can do the same for contrib: this folder
>> https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/
>> could be fetched into a subfolder of blender/release/scripts/addons,
>> like blender/release/scripts/addons/contrib
>>
>> This are source folders, not officially released folders.
>>
>> So if in Scons/CMake we could put a new variable like
>> WITH_CONTRIB_INSTALL:BOOL = OFF (cmake)
>> or
>> WITH_CONTRIB_INSTALL = 'false' (scons)
>>
>> and this would mean that we DON'T copy scripts from
>> blender/release/scripts/addons/contrib in the usual
>> ./blender/scripts/addons or not
>>
>> If we know this and wanto to do it, we set up
>> WITH_CONTRIB_INSTALL:BOOL = ON (cmake)
>> or
>> WITH_CONTRIB_INSTALL = 'true' (scons)
>> to include contrib scripts into out build.
>>
>> Like this, one has to know what he's doing to enable contrib scripts, it
>> cannot happen by default, and this applies also to Graphicall builds.
>>
>> =====================================================
>>
>>
>> Suggestion are more than welcome! :)
>>
>> PS: we're not discussing py security issues here, please dont use this
>> thread to start again discussing about sandboxing and blabla, thanks.
>>
>> Regards,
>> Luca
>>
>> _____________________________
>>
>> http://www.mindrones.com
>> _______________________________________________
>> 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