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
Would the __init__.py be there to actually allow the code to be
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.
> 2/automatically scan plugins dir for some extra file types as data using
> 3/check on python version in setup.py
> You agree with this?
> After installing gramps however via setup.py, this is failing:
> Python 2.7.3 (default, Aug 1 2012, 05:14:39)
> [GCC 4.6.3] on linux2
>>>> from gramps.gen.lib.date import date
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> line 27, in <module>
> from gen.lib.date import Date, DateError, Span
> ImportError: No module named gen.lib.date
> So, this seems to indicate the only solution is to add to all our local
> imports gramps. also. Anybody knows a way around this?
I think with Python 2.x we need to either make it relative (in lib use
"from date import Date, DateError, Span") or absolute (from anywhere
"from gramps.gen.lib.date import Date, DateError, Span").
In Python 3, I think that there are different ways using a dot before
the lib name ("from .date import Date, DateError, Span"). Not sure
> So, in the gen package, we do relative import of gen modules using .. import
> statement, while for import outside of gen package, we add gramps. in front
> of the import.
> Example changes:
> -from gen.ggettext import sgettext as _
> -from gen.ggettext import ngettext
> +from ..ggettext import sgettext as _
> -from gen.lib.styledtexttagtype import StyledTextTagType
> +from styledtexttagtype import StyledTextTagType
> Comments on this? I think it is correct.
Yes, I think that is right. You could (alternatively) add "gramps" to
the Python search path, but that would be consider bad practice.
> 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.
> python setup.py build
> Is this expected, or an error?
> 2012/9/22 Nick Hall <nick__hall@...>
>> On 21/09/12 08:22, Benny Malengier wrote:
>>> Always annoying to have two choices. As you studied this most, please
>>> make a choice for distutils or distutils2.
>> At present, distutils2 still has bugs, so we should use distutils.
>>> What I would like is:
>>> 1. If you do
>>> python setup.py install
>>> in the top directory, Gramps is installed in site-packages/gramps
>> Both of the prototypes install to a standard python location.
>>> 2. We would like also a way however to only install core. This would be
>>> the gen and cli directory. Question is what to do with the plugins, as we
>>> want some plugins in such a core install also (specifically cli reports,
>>> docgen, ...). Perhaps we can just install all plugins also?
>> This should be possible by creating a different configuration file, or
>> adding options to the setup.py file.
>>> Is such a setup possible? Or should we just have people install
>>> everything, and have a flag to setup.py to neglect errors in the gui code
>>> setup (I assume setup.py checks for needed libraries also?)
>> I don't know if setup.py checks for required libraries.
>>> 3. I would test it, but if it works, I plan to delete Makefiles. What use
>>> in keeping something around we don't want to maintain anymore?
>> It will need quite a lot of testing - I was leaving that to Rob.
>> I expect there to be bugs on Windows and Mac installation. Some file
>> paths are not in device independent format (some need to be in Unix format).
>> We also need to check file locations for resource files.
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> Gramps-devel mailing list