Interesting - I think I see what's happening there, but am surprised it
doesn't happen to us both...
At some point over summer, I split aobject (and some other fundamental
modules) off into a separate library, as they weren't very Aesthete
specific. This means, during, start-up Aesthete now tells aobject that
Aesthete is called "aesthete" before anything else happens - aobject uses
this knowledge to fill out the software details, paths and so forth when
Aesthete requests them. As such, Aesthete no longer knows anything about
its installation environment (or shouldn't), aobject covers all that.
The repeated ..'s (in aobject) are a dirty hack to get around the fact we
don't know whether aobject has been installed in a user-defined directory,
as a Python egg, or in system directory, all of which result in different
juxtaposing of the scripts and data. What it does know is the relative path
to '/share' in each of those cases, so it tries each one until it finds the
data and, from then on, appends the relative path onto the script path when
Aesthete calls aobject.paths.get_share_location().
As it was, at the start of the main script (aesthete_ime) there was
import aobject.paths as paths
paths.setup('aesthete')
However, the import was running other setup scripts (e.g.
aobject.details.setup) which needed the name to have been already set.
Anyhow, should be fixed in latest rev.
P
