[Bf-committers] Proposal for moving io scripts into addons
mindrones
mindrones at gmail.com
Wed Jan 12 14:40:53 CET 2011
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
More information about the Bf-committers
mailing list