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.

-Doug

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.

Benny