[Bf-committers] PyAPI breakage and possible solutions
mindrones at gmail.com
Wed Jun 16 16:02:37 CEST 2010
sorry for the long mail, there is some stuff that came up in irc that
I'd like we discuss here.
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 ->
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
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:
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
is fetched into blender/release/scripts/addons.
We can do the same for contrib: this folder
could be fetched into a subfolder of blender/release/scripts/addons,
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)
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)
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.
More information about the Bf-committers