2009/4/24 Doug Blank <doug.blank@gmail.com>

On Fri, Apr 24, 2009 at 4:01 PM, Aaron R. Short <fuzzyfonzy@yahoo.com> wrote:

You are right, but we are also thinking about the library parts of GRAMPS. There may be parts that could be shared, especially after we get a nice separation between backend and frontend. In any event, this will come later, if it comes at all.


ah so like the gedcom handling but shouldn't just those pieces be taken out and made into site-package libraries? It seems heavy handed to make a different app that just wants to use a library of ours to have to install the whole app. Shouldn't a library be focused? ie one thing and one thing well. gramps does so many things that i'd think that seperating it out makes more sense... just a thought.

Yes, that's what I meant: there could be gramps libraries in site-packages, and the gramps app installed as we do now. This would make it easy, for example, to have a web-app that would re-use the libraries.

It is not because we use setuptools that gramps per se must be installed in site-packages, that can be configured easily.
The main point is that GRAMPS is a _pure_ python application, and hence, setuptools is a natural fit to make everything work. Most comments against it come for mixed language applications.
So the future would be to have eg src/gen as a site-package (grampsgen??), and gramps as a python application.
However, I feel that to avoid library naming clashes, we can just as well install all in site-packages under the gramps denomer. Well, I'm really not a packager. I do know you will find on the net a lot more rants against make than you find against setuptools :-) The main point for gramps is there is nobody who at the moment can maintain the make system. People only do copy paste kind of things there.