Your reply message has not been sent.
Your post was successful
This sounds like moving the filesystem walking/compiling/loading code into a separate function. So Plain-PyKE users would then do:The idea I'm planning to try is knowledge_engine.engine intializes itself, but will accept knowledge_bases and rule_bases as arguments ala knowledge_engine.engine(rule_base = joe_rules, knowledge_base = joe_kb)
engine = some_pyke_module.load_engine(...)Rather than calling the engine constructor directly.
This moves the initialization stuff out of the way so that you can do your own initialization in Zope.
I think that this makes a lot of sense.
But, in the meantime, I've refactored the initialization logic and just checked in a first cut at it. I've created a new target_pkg class (in pyke/target_pkg.py) that deals with walking/compiling/loading all of the knowledge bases related to a single 'compiled_krb' directory. I've also changed the initialization logic to allow multiple compiled_krb directories (and hence multiple instances of target_pkg). This was done so that, for example, the web_framework example could just directly use the sqlgen compiled_krb without having to compile its own copy of the sqlgen knowledge base in its own compiled_krb directory. I hope that this is a first step towards allowing a mix of filesystem and ZODB knowledge bases in the same engine (something I want to promote to allow for Zope users to still use filesystem based rule bases -- as well as encouraging Zope developers to consider packaging their rule bases as files so that non-Zope users can also benefit from their work).
This also changes the parameters to engine.__init__ somewhat. Rather than paths (as a tuple) and generated_root_pkg (where the compiled_krb directory is); the new format is simply *paths -- where each path component has its own compiled_krb directory (but allowing multiple path components to specify the same compiled_krb directory). I'm also now requiring that the pyke sources be on the Python Path. Thus, each path argument takes one of the following forms:
So what I now wonder is whether you could add a fourth path option for Zope? This would allow the engine object to be initialized with any combination of filesystem rule bases and Zope bases. If this ends up workable, then maybe we don't need to pull the initialization out of engine.__init__ as a separate function???
OK, all of that said, I've just checked the first version of all of this into svn (rev 172). Give me your sourceforge user id, and I'll add you to the project. This commit isn't quite soup yet, but the changes from here should be small. I've gone ahead and created the zope branch:
$ svn checkout https://pyke.svn.sourceforge.net/svnroot/pyke/branches/zope what_you_call_itThis is a complete copy of trunk as of rev 172.
I would suggest placing your what_you_call_it directory on your Python Path using a .pth file in the site-packages directory rather than setting PYTHONPATH. The problem with PYTHONPATH is that it is still seen by virtualenv copies of Python. You will have to delete any prior installation of PyKE too avoid confusion (or do all of your Zope stuff in a virtualenv?).
Are you developing on Linux? My test scripts and documentation generation scripts are bash scripts...
You will need to be made a project member before you can do the above checkout (using https). You have to do this form of checkout before you can do commits.
Are you a pro with subversion? You will need to regularly merge changes from the trunk back into your branch. I'll try to keep you posted on when I do commits to trunk. Subversion 1.5 has a special way to do this that keeps track of where it is. So you need to be sure to use the right incantation of merge. Ask if you are new to svn.
I guess that you can still provide TTW access to persistent objects that are not derived from Zope.Persistent. So maybe only the engine and/or knowledge_bases have to be Zope.Persistent?? I'm interested to see how this pans out!One another topic --- Do objects destined for the ZODB need to be derived from some kind of zope.persistent class? And, if so, can this be done by multiple inheritance: pyke/knowledge_engine.py: class engine(object): ... pyke/zope/knowledge_engine.py import pyke.knowledge_engine class engine(zope.persistent, pyke.knowledge_engine.engine): ...That's exactly how it is supposed to work. However, that is only necessary when you want/need your classes to be transaction aware. In practice, I think most implementations just make sure their classes are pickle-safe and then handle the Zope stuff outside. Here's my favorite intro: http://www.zope.org/Members/adytumsolutions/HowToLoveZODB_PartI
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.