2012/4/6 Nick Hall <nick__hall@hotmail.com>

I have had a quick look at both distutils and setuptools.  They are quite similar, and I think that we should be able to use either.  We could also consider other build tools such as SCons, but I haven't looked into this.

As far as I understand it, the MANIFEST file defines files that are part of the distribution, not files that will be installed.  All files in the MANIFEST will appear in the tar archive.  The files in the MANIFEST can be defined in the MANIFEST.in file.  With setuptools the default MANIFEST will contain all files under version control.  This is probably fine for most projects.  We may wish to exclude Makefile files if we run both methods for a while.

The files to be installed are defined in the parameters to the setup command.  The easiest method is to install python packages using the packages, package_dir and package_data parameters.  By default, this method installs packages into the dist-packages directory.  In the case of Gramps, we don't have a top level gramps package, so we would have more than one package installed there.  Again, setuptools provides additional functionality to search for packages in the source directory and install associated package data.  The same can be achieved with distutils though.

Alternatively, the data_files parameter can be used to install any files.  By default, data files are installed in a different directory to the python packages.  It is possible to customise this though.  It is quite easy to write a function to return the necessary information to install an entire directory tree.

Script files will be installed to the appropriate directory.  The gramps startup script can be defined using the scripts parameter.  Once more, setuptools may provide some advantages in generating cross-platform scripts (this needs investigating).

Separate processing will be required to generate and install the translation files.  Rob has found a solution to this by defining a custom build class.

I have a few questions to clarify what we are trying to achieve:

1. Is there a preferred build tool?  distutils, distutils2, setuptools or other?

I don't prefer something. An earlier mail indicated distutils2 is the way to go. In my personal experience, I use numpy.distutils, which is not something we can use for Gramps
2. Do we want to install Gramps in dist-packages?

I believe that depends on the distribution. In Ubuntu normal install via package manager would go to dist-packages. So all of gramps should go in


and other programs can use gramps functionality by doing a
from gramps.lib import Person

So one package to install at the moment.
If a user installs himself after downloading gramps, he should remove the installed version by hand (!!!!) and install normally goes into something like


A python setup automatically checks /usr/local/lib after checking /usr/lib.

3. If so, do we want to create a package called 'gramps' to contain all other Gramps packages?

Yes, that is why I say to rename src into gramps, like that it is clear that that folder is essentially what is copied into dist-packages.
In future we might split the core non-gui stuff from the gui, which would allow usage of gramps by eg gramps-connect without install dependency on GTK.
4. Will we want to run the new build tool in parallel with Make for a while?

That seems like double work. If the test in the GEPS shows we can solve all gramps specific problems like the plugin directories without an __init__ file, then I would remove make and convert current trunk to setup.py.

Note that translation is an unknown to me, which is why I suggested Jerome and Rob to look at other python GUI apps on how they install those.




On 05/04/12 09:59, Benny Malengier wrote:
Note that using a MANIFEST file might be a faster way:


2012/4/5 Benny Malengier <benny.malengier@gmail.com>

2012/4/5 Rob Healey <robhealey1@gmail.com>
Dear Benny:

Ok, the files have been moved back to where they belong as they were!

And I did not commit the extra __init__.py files so they are not there anymore....

An __init__ file indicates if a directory is a python module, or just a directory holding data.
So in setup.py, you must indicate this. If you use


then directory tests must have a __init__ file to actually be included.
We don't want the plugins to have an __init__.py, because then top level gramps could import a plugin, while we want the gpr.py files to determine what plugins are actually loaded.

So, for the plugins, and for other files , see section 2.6 and 2.7:


So I would assume in the src directory renamed to gramps we have a setup.py
      package_data={'gramps': ['plugins/*.py', 'plugins/lib/*.py',  ...etc ...]},
Would have to try myself to know if that works.


Sincerely yours,
Rob G. Healey

On Wed, Apr 4, 2012 at 7:05 AM, Benny Malengier <benny.malengier@gmail.com> wrote:

I don't think you fully understand how distutils is supposed to work.
The thing we install is in the current src directory, which we rename to gramps.
The top level stuff, is about our repository. Hence, things like COPYING, TODO, ... are correctly placed there, and have no sense in doc, which is about the official documentation.


2012/3/23 Rob Healey <robhealey1@gmail.com>

In trying to clean up some files in trunk and the new geps for creating the setup.py file, can I have some leeway in moving some files?  For instance, these files:


Can they be moved into the docs directory?  I know that the NEWS file is a list of what has been changed from one release to the next, but why don't we use the ChangeLog file as most projects already do???

Sincerely yours,
Rob G. Healey

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Gramps-devel mailing list

Sincerely yours,
Rob G. Healey

------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ Gramps-devel mailing list Gramps-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gramps-devel

For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
Gramps-devel mailing list