2012/9/29 Doug Blank <email@example.com>
Would the __init__.py be there to actually allow the code to be
On Sat, Sep 29, 2012 at 2:31 PM, Benny Malengier
> Ok, important design decisions, so read following mail, or it is assumed you
> agree :-)
> I have been doing extra changes for the distutils install. Some things I
> think are needed (and I have done locally):
> 1/ also __init__.py files in the plugins directory. I don't like that
> plugins is all data while it is actually code. For the plugins distributed
> with gramps, adding __init__ does not seem like a problem
imported and used, or just to make disutils happy? Currently we don't
add "plugins" to the python search path, so I don't know if this will
cause any conflicts (eg, finding a plugin instead of the gramps code).
We would probably have to add__init__.py files in all the subdirs. It
seems like this would be good to make it so that plugin code could
also be used/reused in other ways.
Yes, we did not want to reuse plugin code. So we introduced lib, which is not the best of constructs in my opinion.
I see Serge already added an __init__ to his maps subdir in lib.
I don't know if it would be possible to find a plugin. Should I add in the __init__ for safety:
__all__ = 
> Nick, I noted however that if I change code in const.py.in
, the old const
> keeps on being used when doing
BTW, I think we can get rid of "const.py.in". The only useful bit in
there is to add the SVN revision number to the Gramps version number,
but there is code in trunk (./src/gen/utils/svn.py) now that can do
that on the fly.
Perhaps that is best, but officially for prefix we still need it. The translation piece uses prefix as fallback, don't know if anybody actually uses that though ...
Version is indeed completely broken in const.py, after I update it for distutils, it would be great if you deprecate version there (version_tuple is hardcoded already anyway, and there is an ugly hack for windows there which hardcodes version also). We also have version duplicate in setup.py now by the way.
The reason const.py does not work with build, is that the write_const_py function is not called for build in setup.py.
It is not called, because @prefix@ is not known when in build, it only is set when install.
As a consequence, build does not know it is /usr/local. Which is normal, when you do build, the path will be something like: ~/gramps/trunk/build/lib.linux-x86_64-2.7
So, I have an ugly hack for that that works fine: do like in windows when build:
if hasattr(install_cmd, 'install_data'):
prefix = "'%s'" % install_cmd.install_data
sysconfdir = "'%s'" % os.path.join(install_cmd.install_data, 'etc')
prefix = 'os.path.join(os.path.dirname(__file__), os.pardir)'
sysconfdir = prefix + ' + "' + os.sep + 'etc"' # Is this correct?
subst_vars = ((u'@VERSIONSTRING@', VERSION),
If nobody has better idea, I'll proceed like that.