[Pipet Devel] Installation + Directory clean-up

Brad Chapman chapmanb at arches.uga.edu
Sat May 13 12:56:10 EDT 2000

> site-packages is for *Python* libraries, modules that are used to 
> programs in Python. 

Okay, if you say so.
> You've won every debate so far, Brad.  But I think I'm right on this 
one ;-)

I think you misunderstand me, Jeff. I have no desire to win debates, I 
just have a desire to make things easier :-). I don't want to put 
stuff in site-packages because I think it is the "right" thing to do, 
nor do I even have any clue about what the "right" thing to do is. I 
just want to put stuff in site-packages because it is the "easiest" 
thing to do given the tools we have.

> Usually programs that run under their own username have a directory 
> /home. 
> Mailman, httpd, and cvs all have directories in /home.  They also 
have shared
> repositories: mailing lists, web pages, and cvs modules, 

I'm afraid this is definately not true across all UNIX systems. Even 
on FreeBSD, which is not that "out there," the /home directory is only 
for users with logins to the computer. So I definately would never 
think that Piper should be installed there.
> If Piper is to have a directory in /home, we need to consider 
whether or not
> Piper will (1) run under its own username 

The only thing that runs under it's own username on my system is stuff 
like the PostgreSQL and MySQL daemons, but we aren't running a daemon, 
right? Plus the home problem I mentioned above (pgsql and mysql users 
don't even get directories in /home).

> and (2) have a shared repository. 

Sure, I would think this makes sense to have a shared respository that 
all of the different users on a machine would have access to. This way 
a sys admin could set up Piper and it would be easy for other users to 
get started with it. But I'm no sys admin -> I'm the only one on my 
machine so it doesn't make much difference if it in my directory or in 
a main directory :-) If you want something like this then it should go 
in $PREFIX/piper, I guess, where prefix defaults to /usr/local and can 
be specified by the user during the build (this is the way things work 
with configure).


Well, one Piper instance per computer. Who wants to install Piper 
multiple times on a single computer? I guess I think that all xml 
generated during runtime should be stored in $HOME/piper (where $HOME 
is the home directory of the user running piper) and that the only way 
to add stuff to $PREFIX/piper is by copying xml files there while 
things aren't running. (so the root user copies them there directly, 
or "installs" them from a repository of useful xml files describing 

> Look at just a few of the applications that have directories in 
> (from
> my own system):

>  rpm/

Why the heck do you have this cruft on your computer? :-)

> BUT, will Distutils handle the installation of libraries into 
> Also, Piper's pixmaps should go under...
>    /usr/share/pixmaps/piper

<sigh> I don't think it will do this. I'll look into it more. Damn, I 
really don't want to have to use autoconf.

> Anyway, what is wrong or difficult about writing a shell script for
> installation that does something like this:
>    mkdir /usr/lib/piper
>    cp -dfpRx uil /usr/lib/piper
>    cp -dfpRx dl /usr/lib/piper

difficult? <- Nothing (although this should be written in python :-)

wrong? <- Lots of things.

1. Not everyone will want things in these directories. I don't care 
about the debate of /usr/local vs. /usr or whatever, I'm just saying 
that things work differently on different systems and having a 
hardcoded build is not a good way to make anyone happy.

2. The original point of talking about this was that we'll need to 
compile extensions. Using hand written Makefiles is *very* bad and 
non-portable (that's why I'm making Jarl fight with autoconf :-).

3. The reason that installation tools are cool is that they provide 
flexibility for the installer _and_ give the developer a lot of tools 
to work with. For instance, both autoconf and distutils make nice 
tarballs for you, distutils will eventually have "binary" creation 
tools, autoconf provides lots of targets like uninstall, etc. Writing 
your installation script is no fun and you get no nice tools.

Anyways, I'll look at Distutils more if we really need to put Piper in 


More information about the Pipet-Devel mailing list