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 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?
2. Do we want to install Gramps in dist-packages?
3. If so, do we want to create a package called 'gramps' to contain all other Gramps packages?
4. Will we want to run the new build tool in parallel with Make for a while?



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 <>

2012/4/5 Rob Healey <>
Dear Benny:

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

And I did not commit the extra 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, 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, because then top level gramps could import a plugin, while we want the 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
      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 <> 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 <>

In trying to clean up some files in trunk and the new geps for creating the 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.
_______________________________________________ Gramps-devel mailing list