[Python-Dev] Where to install non-code files

Greg Ward gward@mems-exchange.org
Fri, 26 May 2000 09:27:16 -0400

On 26 May 2000, Gordon McMillan said:
> Yeah. I tend to install stuff outside the sys.prefix tree and then 
> use .pth files. I realize I'm, um, unique in this regard but I lost 
> everything in some upgrade gone bad. (When a Windows de-
> install goes wrong, your only option is to do some manual 
> directory and registry pruning.)

I think that's appropriate for Python "applications" -- in fact, now
that Distutils can install scripts and miscellaneous data, about the
only thing needed to properly support "applications" is an easy way for
developers to say, "Please give me my own directory and create a .pth
file".  (Actually, the .pth file should only be one way to install an
application: you might not want your app's Python library to muck up
everybody else's Python path.  An idea AMK and I cooked up yesterday
would be an addition to the Distutils "build_scripts" command: along
with frobbing the #! line to point to the right Python interpreter, add
a second line:
  import sys ; sys.append(path-to-this-app's-python-lib)

Or maybe "sys.insert(0, ...)".

Anyways, that's neither here nor there.  Except that applications that
get their own directory should be free to put their (static) data files
wherever they please, rather than having to put them in the app's Python

I'm more concerned with the what the Distutils works best with now,
though: module distributions.  I think you guys have convinced me;
static data should normally sit with the code.  I think I'll make that
the default (instead of prefix + "share"), but give developers a way to
override it.  So eg.:

   data_files = ["this.dat", "that.cfg"]

will put the files in the same place as the code (which could be a bit
tricky to figure out, what with the vagaries of package-ization and
"extra" install dirs);

   data_files = [("share", ["this.dat"]), ("etc", ["that.cfg"])]

would put the data file in (eg.) /usr/local/share and the config file in
/usr/local/etc.  This obviously makes the module writer's job harder: he
has to grovel from sys.prefix looking for the files that he expects to
have been installed with his modules.  But if someone really wants to do
this, they should be allowed to.

Finally, you could also put absolute directories in 'data_files',
although this would not be recommended.

> (Hmm, I guess it is if you use rpms.)

All the smart Unix installers (RPM, Debian, FreeBSD, ...?) I know of
have some sort of dependency mechanism, which works to varying degrees
of "work".  I'm only familar with RPM, and my usual response to a
dependency warning is "dammit, I know what I'm doing", and then I rerun
"rpm --nodeps" to ignore the dependency checking.  (This usually arises
because I build my own Perl and Python, and don't use Red Hat's -- I
just make /usr/bin/{perl,python} symlinks to /usr/local/bin, which RPM
tends to whine about.)  But it's nice to know that someone is watching.

Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367