[Bf-committers] PyAPI breakage and possible solutions

[mindrones]

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