addon dependencies v0.75 (2.59 <-> 2.63a)

this is addon that installs/uninstalls a patch to help in blender addon development and add
a dependencies feature between addons.
it’s more intented to the blender pythonnist community and script developpers.
it removes common annoyances when scripting/enabling/bugging/disabling/reloading etc.


adds a light dependency feature between addons :

    . an addon can declare it needs another addon to be enabled to run.
    . in the case the other addon is not started, it will be done right
      before it (v0.7).
      several parents can be declared, each with their versions.
    . a 'parent' addon can't be disabled if it's currently used by one or
      several other addons. an addon does not need any modification
      to become a 'parent', only the 'child' needs a particular field
      in bl_info
    . the mod is fully compatible with normal addons.
    . the 'childs' addons are fully compatible with the normal version.
    . icons and new fields are displayed when an addon is either a 'child'
      or a 'parent' addon.
    . creation of a 'child' addon is quick : one new field in bl_info. (see below)

improvements for multi-modules addon development :

    . get rid of the "already registered as a subclass" message when
      unregister() was faulty.
    . disabling then enabling an addon will reload and reread every module
      of the addon not only the __init__ file (similar to F8 but for only
      one module, or like the 'add a bug to __init__/reload/correct/reload'
    . support dynamically created class (e.g. generated through exec)
      without complaining.

addons can optionnally be disobedient :

    at register() and unregister steps() an addon could decide to stay
    active. this can be useful for cases where an addon has not finished
    its job: it did not save a file, a modal op. is still running, he is
    still performing a loop, or maybe the user needs to achieve something
    before, etc..
    to achieve this, register() and unregister() can return a simple string
    explaining why the addon desobeys. the message will be reported in the
    ui and in the console.

bugged addon enabled by default are not marked enabled any longer.

wip or unoffical scripts can be stored in a scripts/addons_sandbox folder

    a location for you work before publication or to drop the scripts you find for
    example here and that are not official or contrib.

misc. goodies :

    ui report and icons are used along with console to provide info about
    the cases above. messages from scripts can be displayed in various situation.

nerds friendly (some switches in init to play with)

the patch can be safely enabled and disabled from the user preferences addon tab.

a large README is provided with all of the info !

to link a parent and a child addon is simple. in the init file of the addon, one needs to ass a new field called dependencies

bl_info = {
  <b>  "dependencies" : 'Script Events (0,1)' </b>

for several parent addons :

"dependencies" [/B]: [ 'Script Events (0,1)', 'a second addon (1,2,3)' ] 

as of 0.6 this patch is (from now) provided as an addon

download :
fork :

also available from the meta-androcto svn script collection at sourceforge.

can be used with graphicall builds (see nerds swicthes in README) at your own risk.
( but it’s not too risky.)

if you used v0.6, you should update. simply replace the addons_dependencies folder,
restart, apply, and restart again.

for prior patches (provided as is with the .dependencies extension) you should restore the original files them remove the modded files, then enable the addon (not mandatory but cleaner)

WARNING : it has been tested x 100 on XP, ubuntu 11.10 2.59, 2.60rc and 2.60 in various chaotic cases. everything should be ok for seven and mac else please report. LOTS of info in the readme and documented code.
I’m often on irc #blenderpython for support. in the worst cases, the trunk files are provided and their paths are written in the config file.

that sound great. If you make your script also able to detect download and install those dependencies this scripts will be amazing. You could do that by uploading all latest dependencies into a website , like github and then download and install them on the fly. It should be too difficult to make.

Keep rocking.

So where is the problem ? Check that algorithm gives a solution and then enable the button. Even if the algorith is slow its not a problem cause from my experience the gui updates only the when the mouse hovers it or clicks on it.

You could probably make it intelligent so its does not check the same data more than one time with the algorithm.

updated to 2.5.8a
corrected some bugs
added dependencies icons

I updated a script that uses this dependencies mecanism :
it needs another script to be run. the following line in the init file of the addon tells Blender to seek for the parent addon :

bl_info = {
    "dependencies" : [ ['Script Events',(0,1)] ]

it uses the generic modal, and the generic hud function of script event.

hey again :

allows to work on a multifile module without having to restart Blender at every modification / bug of a sub module.
(this is only about a loop in sys.module, added to the addon disable function, that removes the child modules of the addon, so it can be executed at import time again when they are enabled again). shouldn’t hurt, afaik.

these modifications shouldn’t hurt, at least it works fine at home, but please let me know.

oh, also it should now work when the addons (parents, childs…) are enabled by default.

that sound great. If you make your script also able to detect download and install those dependencies this scripts will be amazing. You could do that by uploading all latest dependencies into a website 

kilon, yes that sounds great but it can become really tricky for both the users and the devs. auto-updates, dependencies check, curl, version managers, woow…

so this mod will stay simple and won’t edit too much file (in fact just one really, the other is about the ui prefs). in fact this mod is essentially a visual trick + a watchdog when you attempt to disable an addon used by another one.

You are absolutely right, its quite alot of work. But no worries , I may implement this for a new project I am thinking of Gyes - Tartartus that will essentially send blender in the cloud and make it possible for the user to have access to all blender’s online resources (add ons included) from inside blender. But I will deal with it after finishing my Gyes - Random Material Generator , probably in 2012. Your add on, make my life easier though and unlike mine which is vaporware, its here , it works and its very easy to use.

Well done and thank you.

This addon (or little hack) is great, it saved me a lot of time and you should propose these two patches to be included in the next official release.

updated for 2.59 (+ some small updates)

(from 2.59 r39307 files)
updated and tested mod for 2.59
added various report() messages
tagged the modded files with a value in order an addon can know wether it’s the mod or the normal code. (optional needs)

lnmod = ( rxxx_blende_release_number , mod_version )

an addon can decide wether or not to enable or disable itself by returning False or any string message like ‘I must write a file before that’. message will be displayed in the console and in the report ui textfield. addon returns nothing or True if everything is ok.

def unregister() :
    [some tests]
    if tests_ok then :
        unregister blah[...]
    else : return "modal operator was still runnning but I'm ok now, you can remove me"

for sure a script using the dependencies field and returning ‘blah’ / False remains compatible with normal files, it just won’t react.

hey thanks pa.basso. I tried first to make me understand by ideasman on irc but I failed in this task for now :slight_smile:

update for 2.60rc, 3 files this time. I changed nothing but 2.60 code is more organized (addon panel operator code moved to a main module full of py operators)

for now it tests if a module is enabled, but it could be interesting to only test wether an addon is here, in case we only need to use the modules of it and not its ui or the whole stuff for example.

updated, now as an addon, heavily tested on XP for now.

there’s no significant changes about the way it works, it’s more like a kind of safe installer/desinstaller.
revision check
currently used files check
compatible with 2.59 and 2.60rc
there’s a big readme inside you should read.

you can read the first post for info and the DL link

thanks for reporting any issue

(I speak like robocop. too much programming)

updated, see 1st post

updated :

    . added a new path for addons, 'scripts/addons_sandbox' :

      from my comprehension about addons folders in /scripts :

          RELEASE SCRIPTS, the official scripts distributed in Blender releases
          are in the 'scripts/addons' folder

          CONTRIB SCRIPTS good for testing but not official scripts yet
          should be in the 'scripts/addons_contrib' folder

          EXTERN SCRIPTS for external projects scripts
          should be in the 'scripts/addons_extern' folder

      so there's no official location for scripts that are still in development
      and shared in some unofficial way (like from Blender Artists) and that
      never dare to go into the process to become a contrib or release script.

      the script collection we can find at
      contains a lot of such 'renegade' scripts, and they are all located in
      addons_extern, which is not the right place, in a long term perspective.
      meanwhile it's very confusing for 'newcoders'. even for more older ones
      like me in fact, who are lost about addons locations and who finally
      understand the whole process about script submissions and addon folders
      concept, after years of misusage :
      I publish 'renegade' scripts since 3 years and tell the users to install
      it in /scripts/addons and only understand today this location is not
      suitable at all. but, there is no official ones. actually nobody told me
      I was wrong : it makes me think a lot of the community still don't get it
      about the way it is organized.
      so I added this category and the corresponding path :

          COMMUNITY SCRIPTS : scripts from non Blender Foundation sources
          for work in progress or not yet submitted addons.
          (use these ones at your own risk)
          should be in the 'scripts/addons_sandbox' folder

    . corrected misc bug for 2.60rc version that did not display the parent
      module in the dependencies field of an addon (user prefs &gt; addon ui)

    . improved reset_all() function. solves a case when two addons enabled by
      default are located in two different folders e.g. the child in
      addons_contrib and the parent in addons_extern.
      the child was not able to enable its parent since the path was not
      already known.

download :
last zip
fork :

I would need a little help :

I think a file checksum check would be more reliable to identify the running files. the actual published version can recognize a modded file, as files are ‘tagged’ with a version number line 20, but it can’t recognize if the current used files are the orignal or not. it only assumes they are the original if they are not the modded ones, and stores them in a folder (/user) of the addon after applying the patch. then you can restore from /user, or from the /ori folder that provides the original files. (bundled in the addon)

right there’s no limitations with that but a CRC test is more accurate. I begun to edit the addon and it looks ok on win XP 32bits but I would need that linux, mac, and 64 bits people run a little tests to be sure that the CRC test returns the same ID for each file. it should but you know, I don’t want my addon to remove your file by mistake because of that. (README or blender project)

so thank you if you a 5 min left for this, ( this is for a fair cause) :

unzip anywhere,
simply open the file in a blender text block
run it (altP) only once nothing is done or written, except that
it creates a new text clock called CRC

it’s nice if you can share the text of it at paste.all or post it here, many thanks for your feedbacks !

also the patch shouldn’t be applied if you run this test. not because it’s dangerous but because it’s less useful.

here you go

from : ???
system : Linux
version :(2, 59, 4) (40827)

  modded :

  running :

(thanks² Kilon !)

updated for 2.60
no feature changes in the patch, only ‘patcher’ modifications.

v0.73 22/10/11
    . 2.60-proof (no changes since rc1)
    . addon version (bl_info) now different from patch version (patch_version)
      plan to only push the patched files and not the addon/patcher in next
    . new config file, that contains the patch related values, will be pushed
      with every new patches.
    . added a crc info about files, not used, did not test on every platform
      yet (verbose = True)
    . added an alias option : when there's no significant changes between two
      revisions, the same patch can be shared between them. files will
      continue to be backupped in the real revision folder.

(also works fine on ubuntu 11.10 (tested 2.59 and 2.60) so mac should be ok (else yell)

updated for 2.60a
no feature changes in the patch, only ‘patcher’ modifications.

v0.74 01/11/11
    . corrected a bug when modded key does not exist
    . checked patch v0.72 with 2.60a and updated config file to support it