[Pipet Devel] Installation + Directory clean-up

[Brad Chapman]

Jeff wrote:
> BTW, what about non-Python UI's?

They will have to have their own installation system. I just don't 
know about any solutions which can effectively manage installations 
for tons of different programming languages, so right now all I'm 
worrying about is the python stuff that we have :-). If a better 
installation mechanism exists that can handle tons of languages and 
will do this generally, that would be better, but I just don't know 
what that would be... 
    In general, I don't know exactly how we are going to handle 
non-python ui's. I guess it will depend on what language they are 
written it.

> Okay, then you're talking about just the Python stuff (UIL and DL), 
because
> Distutils doesn't handle C/C++.  Right?

Distutils only handles C/C++ that is being build explicitly for the 
purpose of being imported into a python program (ie. wrapped C/C++ 
code). There is no way it is as well suited for handling compiling big 
C/C++ programs like Overflow and GMS as autoconf is.

> Yes, it'd be MUCH easier to re-import everything.  (Getting rid of 
"library"
> will also break a lot of things :-( )

Nah, just the import statements and xpm directories, right? I've been 
trying to put the directories for xpms into constants so that it would 
be easier to fix problems like this.
 
> Could we use "uil" instead of "ui"?  Just semantics here, but we're 
really
> talking about a "layer".  The UIL is a layer comprised of multiple 
UI's, and
> more than one UI will go in the "uil" directory.

I don't care :-). Seriously, naming doesn't mean much to me, as long 
as decide on something and stick with it.
 
> Hold on a sec.  My understanding is that the "site-packages" 
directory is
> used
> for Python development modules/libraries and not for applications.  
Have you
> heard or seen otherwise?  Are we considering most of Pied and the DL 
to be
> development libraries like PyGTK?

Is it really this well defined? It seems like the site-packages 
directory is for libraries, and the loci code is still a library, it 
is just that we use it and not anyone else :-). I didn't really know 
that their was a standard on this. By putting a piper module there we 
really aren't competing with anyone's namespace, so I don't really see 
what the big problem with it is.
    Fnorb, for instance, actually has it's fnidl script inside of 
site-packages (so that you set your $PATH to include this script 
inside of site-packages) so all of the code for running this script is 
inside site-packages. 

> Also, something like...
>    /usr[/local]/lib/piper
> would be acceptable for Unix systems.

Well, if we put it in site-packages, we would be putting it in 
/usr/local/lib/python1.5/site-packages/piper... Why is this not 
appropriate?

> I actually had this discussion with the author of Anaconda (the 
RedHat
> installer) when he put an Anaconda file called "gui.py" in the 
site-packages
> directory.

Well, this is kind of an ugly namespace violation (much the way 
orbit-python sucks up the namespace CORBA by putting its module right 
in site-packages), but we won't be doing this because everything will 
be inside of a piper module.
 
> Don't we need a home directory for Piper anyway?  I was thinking of 
putting
> the Python code in something like /home/piper, and then a symlink 
can go in
> /usr/bin.

Why do we need a home directory explicitly for Piper? If we start 
doing stuff like this they we'll have to start writing our own 
installation scripts. <sigh> I'm just trying to make use of what is 
already available to do our installation for us. What kind of stuff 
would we be putting in this home directory that makes it necessary?

Brad