[Bf-committers] PyAPI breakage and possible solutions

[Bassam Kurdali]

Scripts that are bundled with Blender release must be working, correct?
bf-extensions tracker having a broken category doesn't seem bad, since
this is not release. script maintainers then have the responsibility of
keeping their own scripts working.
API breakage is a temporary problem; once blender reaches release
status, I suspect Python api won't be changing for quite some time.
I don't see why moving extensions to graphicall really changes anything.

On Wed, 2010-06-16 at 08:10 -0600, Daniel Salazar - 3Developer.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