[Bf-committers] Proposal for moving io scripts into addons
Campbell Barton
ideasman42 at gmail.com
Fri Jan 14 06:37:14 CET 2011
Hi Luca, while having a clearer division between core and community
scripts could be good I don't there is one thing I don't agree with.
>From what I can see with your proposal:
current bundled "addons" become "extensions" and can be enabled by
default, and community maintained addons (currently contrib addons),
become "addons".
To me this isn't a useful distinction to make, to the point of giving
them different names since they are essentially the same thing from
different places.
If we need to tag scripts this can be a field in the script metadata
and displayed in our UI so its clear that some addons are community
maintained, downloaded from a 3rd party. bundled etc.
to me an "addon" is just a standalone component which can be
enabled/disabled, I don't see a problem with having a few officially
maintained addons enabled in our default preferences.
Aside from this one point your suggestions seem reasonable, at the
moment the layout of scripts directories will probably need updating
in the future though I'm inclined to wait-and-see since I don't think
the current layout is holding back development.
In short, Id like to go ahead with my smaller proposal and move io
scripts to addons, and I'm open to larger changes in the future but
don't think they need to be made right now.
- Campbell
On Wed, Jan 12, 2011 at 1:40 PM, mindrones <mindrones at gmail.com> wrote:
> Hi,
>
> after discussing this with Campbell in IRC, we decided to propose the
> scheme you find below (see "PROPOSAL").
>
> For those interested in details, under the proposed scheme there is some
> background information that you can skip at will (the "APPENDICE:
> BACKGROUND ..." section).
>
> I've paste this proposal also here:
> http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/Infrastructure
>
> If this will be accepted I'll wikify this in the guidelines.
>
>
> Regards,
> Luca
>
>
>
> INTRODUCTION
> ================================================================================
>
> What's "bf-extensions"
> --------------------------------------------------------------------------------
>
> Back in 2008, after discussing with Nathan Letwory we designed the
> bf-extensions repository classifying as "extensions" things like:
> * Python Scripts
> * C/C++ Plugins
> * Verse
> * (in the future maybe)
> * Lua Scripts
> * javascript Scripts
> * ?
>
> Problem
> --------------------------------------------------------------------------------
>
> In the last 2 years there has been quite a naming misunderstanding.
>
> "addon" = can be enabled
>
> NO!
>
> "addon" = comes with the Release or not? (a là Firefox)
>
> Bf-extensions was rather designed like this:
>
> * an "extension":
> - is pre-installed (comes with blender releases)
> - can be on/off by default
> - can be enabled/disabled
> - Release would not have "addons" in the Blender home directory
>
> * an "addon":
> - have to be downloaded
> - is off by default after download
> - can be enabled/disabled
> - can be moderately buggy (See below)
> - fix can be provided in contrib/
> - fixed versions:
> - shows in addons panel (or info header, to be decided)
> - user can accept upgrade and download it
>
>
> PROPOSAL
> ================================================================================
>
> So this is the proposal to put things in the right perspective.
>
>
> SVN
> --------------------------------------------------------------------------------
>
> bf-blender/ [1]
> blender/
> trunk/
> release/
> scripts/ ¦
> core/ ¦
> ui/ ¦
> modules/ ¦ bf-extensions/ [2]
> presets/ ¦ trunk/
> extensions/ <···· svn-external ····> scripts/
> io_* ¦ io_*
> render_* ¦ render_*
> mesh_* ¦ mesh_*
> ... ¦ ...
> (no "addons") ¦ addons/
> ¦ scripts/
> ¦ io_*
> ¦ render_*
> ¦ mesh_*
>
> [1] https://svn.blender.org/svnroot/bf-blender
> [2] https://svn.blender.org/svnroot/bf-extensions (rename "contrib" as
> "addons")
>
>
> USER HARD DISK
> --------------------------------------------------------------------------------
>
> BLENDER-HOME/
> scripts/ ¦
> core/ ¦
> ui/ ¦
> modules/ ¦ bf-extensions/
> presets/ ¦ trunk/
> extensions/ ¦ scripts/
> io_* ¦ io_*
> render_* ¦ render_*
> mesh_* ¦ mesh_*
> ... ¦ ...
> ... ¦ addons/
> addons/ <···· user download ····> scripts/
> io_* ¦ io_*
> render_* ¦ render_*
> mesh_* ¦ mesh_*
>
>
>
> (same scheme in different fashion)
> --------------------------------------------------------------------------------
>
> bf-extensions/
> trunk/
> scripts/ <------- (svn-external)
> io_* ¦
> render_* ¦
> mesh_* ¦
> .../ ¦
> addons/ ¦
> scripts/ <~~~~~~~~~~~ (downloadable)
> io_* ¦ |
> render_* ¦ |
> mesh_* ¦ |
> .../ ¦ |
> ¦ |
> scripts/ ¦ |
> core/ ¦ |
> ui/ ¦ |
> modules/ ¦ |
> presets/ ¦ |
> extensions/ <--- |
> io_* |
> render_* |
> mesh_* |
> .../ |
> addons/ <~~~~~~~~~~~
> io_*
> render_*
> mesh_*
>
>
>
>
>
> APPENDICE: BACKGROUND ABOUT BF-EXTENSIONS REPOSITORY AND PROBLEMS
> ################################################################################
>
> Current situation
> ================================================================================
>
> Currently we had a svn-external setup such as release/scripts/addon/ dir
> points to bf-extensions, like this:
>
> bf-blender/
> trunk/
> release/
> scripts/
> addons/ <-- svn-external pointing to [1]
> io/
> keyingsets/
> modules/
> op/
> presets/
> templates/
> ui/
>
> [1] https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/
>
> Benefits
> --------------------------------------------------------------------------------
>
> Like this, people develop in bf-extensions svn and scripts that are in
> [1] go in release/scripts/addons.
> Whatever we develop outside of bf-extensions/trunk/py/scripts/addons/ is
> ignored by bf-blender svn, so that we are free to develop in
> bf-extensions and move stuff in bf-extensions/trunk only when things are
> useful and stable.
>
> Limitations
> --------------------------------------------------------------------------------
>
> When you do checkout bf-blender, you read something like:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> $ svn up
> U release/scripts/op/io_scene_x3d/import_x3d.py
> U release/scripts/op/io_scene_x3d/__init__.py
> U source/blender/modifiers/intern/MOD_smoke.c
>
> Fetching external item into 'release/scripts/addons'
> Updated external to revision 1388.
>
> Updated to revision 34281.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This means that svn go fetching addons in [1] and this takes a bit of
> extra time than having addons/ dir in bf-blender.
>
>
> Problem
> ================================================================================
>
> The svn-external property is limited to directories.
>
> If we wanted to develop for example also io/ in bf-extensions, we would
> have to do this:
>
> bf-blender/
> trunk/
> release/
> scripts/
> addons/ <-- svn-external pointing to [1]
> io/ <-- svn-external pointing to [2]
> keyingsets/
>
> [2] https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/io/
>
> but to checkout bf-blender we would get:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> $ svn up
> U release/scripts/op/io_scene_x3d/import_x3d.py
> U release/scripts/op/io_scene_x3d/__init__.py
> U source/blender/modifiers/intern/MOD_smoke.c
>
> Fetching external item into 'release/scripts/addons'
> Updated external to revision 1388.
>
> Fetching external item into 'release/scripts/io'
> Updated external to revision 1388.
>
> Updated to revision 34281.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> which would mean the extra time to fetch scripts would be doubled...
>
>
>
> _____________________________
>
> http://www.mindrones.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
--
- Campbell
More information about the Bf-committers
mailing list