A while back I posted my plugin framework module asking for feedback I only got one person to respond but that just fine, they gave me plenty to think on. I'm back to showcase my improvements.
https://github.com/Ryex/pyitect The biggest change in V2 is that Python versions 2.6 and up are supported with no loss of functionality. for some reason I blanked the existence of imp I know about it but forgot for around a year, it's weird. Regardless, Python 3.3 and lower uses imp and python 3.4 and up uses importlib. The second biggest change is that the magic module PyitectConsumes is no longer used for import time component loading. one of the feedback's was that this was just too much magic going on with the import machinery. Instead, pyitect has a empty sub-module pyitect.imports . this module is populated with components during import of a plugin module so insted of from PyitectConsumes import foo you use from pyitect.imports import foo the difference may seem semantic but the difference is that where as PyitectConsumes just magically existed during import pyitect.imports always exists but is empty unless a plugin module is getting imported In pyitect that is a difference between import-time and run-time component fetching. for former makes components declared in the configuration file of the plugin available while the plugin's module is still being loaded. The latter is invoked on a plugin system instance via it's load method. Plugins MAY need to use run-time component acquisition in V1 this was possible but author of the system needed to make the plugin system instance available to the author. V2 makes this much easier by letting the instance hangout in the pyitect module build_system, get_system, and destroy_system all work with a global instance of the pyitect.System class. in V1 version postfixes was a system to provide different types of the same component. their use however was a bit arcane. In V2 the functionality of post-fixes is instead accomplished with component subtypes. if a component is names with a doted notations ie. "compa.sub1.sub2" each part represents a subtype of the part before it. so a "a.b.c" is also a "a.b" and an "a" type component. if a component type "a" is requested a "a.b" may be returned if an "a" is not available. all this behavior can of course be modified. I've also written up sphinx docs this time http://pyitect.readthedocs.org/en/latest/ I would like more feedback if anyone has the time avalible to look at it. Thanks ~ Benjamin "Ryex" Powers -- https://mail.python.org/mailman/listinfo/python-list
