In trying to fix the bug reported by Emma, I am going to need to
further redo how the PyKE engine initialization finds its source
files.
The 0.6 pyke.knowledge_engine.engine parameters include a tuple of
paths (defaulting to ('.',)) and a generated_root_pkg (defaulting to
'compiled_krb').
This currently lets you place your .krb files anywhere (not
necessarily on the Python Path). The examples all place the .krb
files in the same directory as the .py source files. This means that
the .krb files are in a directory accessible from the Python Path and
in the same directory as the .py module creating the engine object.
The problem is that easiest way to specify the paths is as a relative
path (hence the default of '.'), but on Windows, the program's current
working directory is often meaningless and arbitrary.
So I'm wondering whether anybody would mind terribly if I changed the
paths to be Python dotted module paths. This would require that the
location of your .krb files also be accessible (possibly indirectly)
from your Python Path. It would also require that you have an
__init__.py file in this directory to mark it as a Python package.
Please respond ASAP so that I can proceed with this.
There is no problem but it seems that i was the only one working on
windows and i am not using it under windows anymore, so i don't mind
if you deprecate windows version :P.
> In trying to fix the bug reported by Emma, I am going to need to
> further redo how the PyKE engine initialization finds its source
> files.
> The 0.6 pyke.knowledge_engine.engine parameters include a tuple of
> paths (defaulting to ('.',)) and a generated_root_pkg (defaulting to
> 'compiled_krb').
> This currently lets you place your .krb files anywhere (not
> necessarily on the Python Path). The examples all place the .krb
> files in the same directory as the .py source files. This means that
> the .krb files are in a directory accessible from the Python Path and
> in the same directory as the .py module creating the engine object.
> The problem is that easiest way to specify the paths is as a relative
> path (hence the default of '.'), but on Windows, the program's current
> working directory is often meaningless and arbitrary.
> So I'm wondering whether anybody would mind terribly if I changed the
> paths to be Python dotted module paths. This would require that the
> location of your .krb files also be accessible (possibly indirectly)
> from your Python Path. It would also require that you have an
> __init__.py file in this directory to mark it as a Python package.
> Please respond ASAP so that I can proceed with this.
This logic is one of the things I'd pull out into a separate class to
modularize for ease of porting to non-filesystem based persistence,
but I think maybe there would be payoff even for supporting different
OS filesystems.
Try to think of this as a language translation problem. Current
working directory is really an idiom for "stuff I'm working on now." I
think './' is a reasonable default path for unix-y operating systems,
but in Windows it's probably something like "%HOMEDRIVE%%HOMEPATH%
\Desktop". It's common to have different default behavior for
different OS flavors in order to try and be a good citizen in each.
I assume you just want to leverage the python import to deal with OS
file search idiosyncrasies?
On Jan 10, 3:27 pm, dangyogi <dangy...@gmail.com> wrote:
> In trying to fix the bug reported by Emma, I am going to need to
> further redo how the PyKE engine initialization finds its source
> files.
> The 0.6 pyke.knowledge_engine.engine parameters include a tuple of
> paths (defaulting to ('.',)) and a generated_root_pkg (defaulting to
> 'compiled_krb').
> This currently lets you place your .krb files anywhere (not
> necessarily on the Python Path). The examples all place the .krb
> files in the same directory as the .py source files. This means that
> the .krb files are in a directory accessible from the Python Path and
> in the same directory as the .py module creating the engine object.
> The problem is that easiest way to specify the paths is as a relative
> path (hence the default of '.'), but on Windows, the program's current
> working directory is often meaningless and arbitrary.
> So I'm wondering whether anybody would mind terribly if I changed the
> paths to be Python dotted module paths. This would require that the
> location of your .krb files also be accessible (possibly indirectly)
> from your Python Path. It would also require that you have an
> __init__.py file in this directory to mark it as a Python package.
> Please respond ASAP so that I can proceed with this.
> There is no problem but it seems that i was the only one working on
> windows and i am not using it under windows anymore, so i don't mind
> if you deprecate windows version :P.
> > In trying to fix the bug reported by Emma, I am going to need to
> > further redo how the PyKE engine initialization finds its source
> > files.
> > The 0.6 pyke.knowledge_engine.engine parameters include a tuple of
> > paths (defaulting to ('.',)) and a generated_root_pkg (defaulting to
> > 'compiled_krb').
> > This currently lets you place your .krb files anywhere (not
> > necessarily on the Python Path). The examples all place the .krb
> > files in the same directory as the .py source files. This means that
> > the .krb files are in a directory accessible from the Python Path and
> > in the same directory as the .py module creating the engine object.
> > The problem is that easiest way to specify the paths is as a relative
> > path (hence the default of '.'), but on Windows, the program's current
> > working directory is often meaningless and arbitrary.
> > So I'm wondering whether anybody would mind terribly if I changed the
> > paths to be Python dotted module paths. This would require that the
> > location of your .krb files also be accessible (possibly indirectly)
> > from your Python Path. It would also require that you have an
> > __init__.py file in this directory to mark it as a Python package.
> > Please respond ASAP so that I can proceed with this.
Jeremy wrote: > Try to think of this as a language translation problem. Current > working directory is really an idiom for "stuff I'm working on now." I > think './' is a reasonable default path for unix-y operating systems, > but in Windows it's probably something like "%HOMEDRIVE%%HOMEPATH% > \Desktop". It's common to have different default behavior for > different OS flavors in order to try and be a good citizen in each.
> I assume you just want to leverage the python import to deal with OS > file search idiosyncrasies?
Yes, but even ignoring the OS idiosyncrasies, it seems like the pyke sources are always intermingled with the python sources. So, since python already has a mechanism to locate python sources it seems to make sense to leverage off of that mechanism rather than developing some other mechanism for Pyke.
Another mechanism for Pyke would also mean that developers would have yet another mechanism to set up and configure. So using the already configured python mechanism seems easier for the developer using Pyke too.
