[Pipet Devel] Installation + Directory clean-up

[Brad Chapman]

Jeff wrote:
> (1) Are you talking about a tool that the user will need to INSTALL 
Piper, or
> a tool that the developers will use to PACKAGE Piper?

You can think of Distutils as being analagous to autoconf/automake, 
except that it is designed for dealing with python installations and 
not C/C++ installations. So it is primarily a tool to make it *really* 
easy to install Piper, but also contains stuff to help with packaging 
(like a target that will generate a .tar.gz automagically).

> (2) What parts of Piper will be "managed" by this tool?  Just the 
Loci stuff
> (UIL and DL) or all parts (including the BL and PL)?

This is definately not a replacement for autoconf/automake, so this 
would just be used to manage installation of the python parts of the 
program. So I guess the idea is that Piper, as it stands right now, 
will be distributed in two "sections": 

1. the pyGTK UI and the dl -> Distutils installation
2. the BL and PL (GMS and Overflow) -> autoconf/automake installation
 
> It would be nice if the user could just type "install".

Well, Distutils is close. To install everything you need to type:

python setup.py install

How's that? :-)

[...snip...my description of autoconf/automake for python...]
> Are you referring to James Henstridge's tools?

Either his tools or stuff separately done by Andrew Dalke could be 
used for installation if we want to go the autoconf route. Either way, 
there will be some serious patching to autoconf and automake for 
Piper developers.

My personal opinion is that we should go the Disutils route. This is 
going to be the standard way to distribute and install python programs 
(since it is going to be included as standard in the python 1.6). 
Autoconf was never really designed for python, and so I think putting 
it together is a big mess we don't need. It should be easy enough to 
tie the python Distutils build with the configure builds for the bl 
and pl, if we want the user to be able to type one command and get 
everything installed.
    To do this, we just need to call './configure && make && make 
install' after the Distutils finishes installing the python parts of 
the program, and this is really easy to do.

[...snip...my description of my plan for a new package structure...]

> Okay, are we merging Loci with GMS and Overflow at this point?  
Because I'm
> confused why you're referring to the "old" Loci structure, which has 
a
> "front"
> directory.  And "front" == "UIL" (User Interface Layer) now, and it 
should be
> separated from your own DL.  Correct?

Sorry, I should have been referring to things as the ui and dl, I was 
just trying to use the old directory structure so it would make more 
sense what I was trying to say about rearranging (of course, it ended 
up making less sense :-). Yes, I am definately talking about making 
this new directory structure complient with merging with GMS and 
Overflow. 

> If you want to eliminate "library", that's fine with me.  I think 
"widgets"
> should probably go into the "gnome" (I'll probably rename it "Pied" 
soon)
> directory too.

Okay, I'm going to cut library in everything then. What I'll do is 
make a new directory structure on my local machine and then make a 
tar.gz and let people take a look at it to see what they think and we 
can kind of hash it out that way. I'll take the fun responsibility of 
merging work done in cvs in the meantime into this new directory 
structure. I'll get the new directory structure installing with 
Distutils, so everyone can look at how that works first hand. It is 
really smoov, so I'm sure everyone will dig it. Then once we get stuff 
hashed out, we can work on fixing cvs (maybe we should just import the 
new structure as  a new module--> piper.

>> 2. Cut the stuff which is supposed to hold code out of the 'back.'
>> The functionality that was supposed to be here is now in GMS, so we
>> don't need the library/modules directories here.
> 
> Yeah, that makes sense.  I thought much of it would move to the DL 
as well.

Thinking about it more, I'd like to completely get rid of both 'main' 
and 'back'. So what would be left is the following type of structure.

piper
    ui -> What is currently in 'front'
    dl -> what is currently in 'middle'
    piper_config.py -> What is currently in const.py. The piper 
configuration
    file.
    piper -> The main executable.

So then during the install, we will install the piper directory with 
all of the libraries that make things work inside of the 
'site-packages' directory, and install the piper executable in 
<prefix>/bin (where <prefix> is specified as a flag during the install 
(just with with autoconf)). 
    Now that we are installing things, we will also not be able to 
save temporary and permanent xml files "inside of" the directory 
structure (since otherwise the user will have to run stuff as root to 
write things inside the directory structure, which is not a good 
thing). I'd like to suggest that we store all xml for piper inside 
$HOME/piper, where $HOME is the environmental variable specifying the 
home of the user running piper. How does this sound to people? 
    
Brad