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
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:
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
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
So, for the plugins, and for other files , see section 2.6
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
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
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.