[Bf-extensions-cvs] SVN commit: /data/svn/bf-extensions [925] extern: == External Addons ==
Luca Bonavita
mindrones at gmail.com
Thu Aug 19 18:28:59 CEST 2010
Revision: 925
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-extensions&revision=925
Author: mindrones
Date: 2010-08-19 18:28:59 +0200 (Thu, 19 Aug 2010)
Log Message:
-----------
== External Addons ==
- moved the folder external/ --> extern/
- rewritten a new tentative workflow for external addons, after discussions with dougal2 (luxrender), kerbox (yafaray), xat (gamekit),
campbell, I'll discuss again to see if I forgot anything and to check with campbell and kaito, before actually coding this infrastructure.
Added Paths:
-----------
extern/
extern/README.rst
Removed Paths:
-------------
extern/README.txt
external/
Copied: extern (from rev 923, external)
Copied: extern/README.rst (from rev 923, external/README.txt)
===================================================================
--- extern/README.rst (rev 0)
+++ extern/README.rst 2010-08-19 16:28:59 UTC (rev 925)
@@ -0,0 +1,573 @@
+
+HOW DO WE ENABLE ONLINE EXTENSIONS?
+================================================================================
+
+When user opens the userpref panel:
+
+* Blender inspects directories
+ * bf-extensions/contrib
+ * bf-extensions/enternal
+ to get bl_addon_info dict for all scripts.
+
+* userpref panel shows these info as if the scripts came in the official blender distribution.
+
+* if the user tries to enable a certain addon:
+ * Blender asks permission to download it
+ * if the script needs a binary to work, then Blender also asks if the user wants to download the bin itself
+ exposing the size in MB
+ * if the user accepts, downloads the addon package (eventually inclusing the binary)
+
+* once this succeeded, Blender enables the addon.
+
+
+HOW DO WE SETUP PYTHON SCRIPTS WHICH DEPEND ON BINARIES TO WORK?
+================================================================================
+
+If the script needs a binary to work, then:
+ * it is required that the addon is a python package (dir + __init__.py)
+ * the binary has to go in a subfolder of the package
+
+In bf-extensions svn we have:
+
+extern
+└── py
+ └── scripts
+ └── addons
+ └── <addon package>
+ ├── __init__.py <-- bl_addon_info goes here
+ ├── module/
+ │ └── <script.py>
+ │ └── <script.py>
+ │ └── ...
+ ├── module/
+ │ └── <script.py>
+ │ └── <script.py>
+ │ └── ...
+ └── bin/
+ └── <exe>
+ └── <exe>
+ └── ...
+
+In our home dir we have:
+
+.blender
+└── 2.53
+ └── scripts
+ └── addons
+ └── <addon package>
+ ├── __init__.py <-- bl_addon_info goes here
+ ├── module/
+ │ └── <script.py>
+ │ └── <script.py>
+ │ └── ...
+ ├── module/
+ │ └── <script.py>
+ │ └── <script.py>
+ │ └── ...
+ └── bin/
+ └── <exe>
+ └── <exe>
+ └── ...
+
+
+WHY DO WE NEED AN EXTERN/ FOLDER IN SVN?
+================================================================================
+
+If a script is developed in an external project, developing it also in bf-extensions
+svn is not an option because this would cause confusion, possible forking and difficulties
+in merging separate versions.
+
+Also, if the script pretends to download a binary compiled from a source code not
+developed on blender.org servers, then blender.org won't distribute the addon,
+neither in official releases, nor from blender.org servers. In this case it will be
+asked the addon developer to develop outside of blender.org svn and use extern/ directory
+as described below.
+
+
+PRACTICAL EXAMPLE
+================================================================================
+
+This example is based on a discussion with dougal2 (lux), Kerbox (yafaray) and
+xat (gamekit).
+
+Here I use Lux as a practical example.
+
+Legenda:
+
+"luxrender" = name of the addon
+"luxblend" = python exporter blender -> lux, it can:
+ - export ascii file to be read, or
+ - use pylux to show lux renders inside blender render view
+"pylux" = name of the binary
+
+
+INITIAL SITUATION
+--------------------------------------------------------------------------------
+
+We start with:
+- Blender 2.53 (which has a 2.53 Python API)
+- Lux 0.7
+
+In bf-extensions we have:
+
+extern
+└── py
+ └── scripts
+ └── addons
+ └── luxrender
+ ├── 0.7
+ │ └── luxblend-2.53
+ │ └── __init__.py
+ │ └── ...
+ └── pylux.py
+
+The file "pylux.py" contains the dictionary below: for every blender version
+we report the urls where we can get a certain version of the needed binary.
+URLs can be missing if a build for a certain platform isn't available.
+
+bl_addons_urls = {
+ (2,5,3):
+ {
+ (0,7):
+ {
+ 'linux-32':'<URL for Lux 0.7>',
+ 'linux-64':'<URL for Lux 0.7>',
+ 'windows-32':'<URL for Lux 0.7>',
+ 'windows-64':'<URL for Lux 0.7>',
+ 'osx-intel':'<URL for Lux 0.7>',
+ 'osx-ppc':'<URL for Lux 0.7>'
+ }
+ }
+ }
+
+Locally we have:
+
+.blender
+└── 2.53
+ └── scripts
+ └── addons
+ └── luxrender
+ └── 0.7
+ ├── luxblend
+ │ └── __init__.py <-- bl_addon_info['version'] = (0,7,0)
+ │ └── module/
+ │ └── module/
+ │ └── ...
+ └── pylux
+ └── <exe>
+
+
+IMPORTANT NOTE
+--------------------------------------------------------------------------------
+
+These URLs must have a baseurl permitted by Blender, so that we know
+that the source is somewhat trusted.
+
+We shouldn't permit personal builds neither from individuals sites neither
+from graphicall.org or similar sites.
+
+It is desirable that developers of a big project accept the responsability to give
+secure and working binaries.
+
+In this case only luxrender.net or its subdomains would be accepted for the script
+to be distributed from blender.org.
+
+
+BLENDER API FIXES
+--------------------------------------------------------------------------------
+
+It must be agreed that when Blender API changes, Blender API developers can do fixes
+to python files in external/py/scripts/addons/
+
+These fixes have to be merged in the Lux repository, where their development can then go on.
+
+These fixes should not cause a bump in the addon version.
+
+
+ADDON BUG FIXES/ENHANCEMENTS
+--------------------------------------------------------------------------------
+
+When the addon developers fix a bug in the addon, they should bump the least significant
+number in their version.
+
+For example:
+* Lux has a 2 numbers in its version (ex: 0.7), hence the bugfixed addon
+should have version = 0.7.1 (still in sync with pylux 0.7)
+* yafaRay has 3 numbers in its version (ex: 0.1.2), hence the bugfixed addon
+should have version = 0.1.2.1 (still in sync with yafapy 0.1.2)
+
+When the addon is copied in bf-extensions, users should get notified at blender startup,
+in a non-intrusive or blocking way.
+
+Using alert in the info header is a good way to do this.
+The option of being notified when addons changes should be a userpreference, so that
+we avoid annoying users if they don't like this feature.
+
+.blender
+└── 2.53
+ └── scripts
+ └── addons
+ └── luxrender
+ └── 0.7
+ ├── luxblend
+ │ └── __init__.py <-- bl_addon_info['version'] = (0,7,1)
+ │ └── module/
+ │ └── module/
+ │ └── ...
+ └── pylux
+ └── <exe>
+
+
+BINARY BUG FIXES/ENHANCEMENTS
+--------------------------------------------------------------------------------
+
+The same applies to the python bindings.
+
+If pylux 0.7 gets a bugfix, it should be called "pylux 0.7.1" so that eventually
+luxblend 0.7.3 can work with pylux 0.7.1 because they both belong to the 0.7 series.
+
+As for the addon, the user should be notified by this and a new version of the binary
+should be downloaded after user acceptance.
+
+.blender
+└── 2.53
+ └── scripts
+ └── addons
+ └── luxrender
+ └── 0.7
+ ├── luxblend
+ │ └── __init__.py <-- bl_addon_info['version'] = (0,7,?)
+ │ └── module/
+ │ └── module/
+ │ └── ...
+ └── pylux
+ └── <exe> <-- 0.7.3
+
+
+NEW LUX RELEASE, SAME BLENDER SERIES
+--------------------------------------------------------------------------------
+
+Later, Lux devs release Lux 0.8.
+
+In bf-extensions we have:
+
+extern
+└── py
+ └── scripts
+ └── addons
+ └── luxrender
+ ├── 0.7
+ │ └── luxblend-2.53
+ │ └── __init__.py
+ │ └── ...
+ ├── 0.8
+ │ └── luxblend-2.53
+ │ └── __init__.py
+ │ └── ...
+ └── pylux.py
+
+
+While pylux.py is:
+
+bl_addons_urls = {
+ (2,5,3):
+ {
+ (0,8):
+ {
+ 'linux-32':'<URL for Lux 0.8>',
+ 'linux-64':'<URL for Lux 0.8>',
+ 'windows-32':'<URL for Lux 0.8>',
+ 'windows-64':'<URL for Lux 0.8>',
+ 'osx-intel':'<URL for Lux 0.8>',
+ 'osx-ppc':'<URL for Lux 0.8>'
+ },
+ (0,7):
+ {
+ 'linux-32':'<URL for Lux 0.7>',
+ 'linux-64':'<URL for Lux 0.7>',
+ 'windows-32':'<URL for Lux 0.7>',
+ 'windows-64':'<URL for Lux 0.7>',
+ 'osx-intel':'<URL for Lux 0.7>',
+ 'osx-ppc':'<URL for Lux 0.7>'
+ }
+ }
+ }
+
+
+DOWNLOAD POLICY
+--------------------------------------------------------------------------------
+
+User should have the chance to keep major versions of the addons and of the bindings.
+I would suggest that minor changes get overwritten, so:
+* luxblend 0.7.11 would overwrite 0.7.10
+* pylux 0.7.3 would overwrite 0.7.2
+
+When it comes to the next major version, in out example (luxblend 0.8/pylux 0.8)
+we should implicitly assume a "0.8.0", and in this case
+* luxblend 0.8.0 would NOT overwrite 0.7.11
+* pylux 0.8.0 would NOT overwrite pylux 0.7.3
+
+This would be the reason why we don't put subversion in pylux.py, we just
+remember the major serie (for Lux 0.7, 0.8, ..., for yafaRay 0.1.2, 0.1.3, ..., etc)
+
+.blender
+└── 2.53
+ └── scripts
+ └── addons
+ └── luxrender
+ ├── 0.7
+ │ ├── luxblend
@@ Diff output truncated at 10240 characters. @@
More information about the Bf-extensions-cvs
mailing list