[Bf-committers] PyAPI breakage and possible solutions

[Daniel Salazar - 3Developer.com]

 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
>