[Python-Dev] Where to install non-code files
Fri, 26 May 2000 10:56:27 -0400
Greg Ward wrote:
> 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".
Hmm. I see an application as a module distribution that
happens to have a script. (Or maybe I see a module
distribution as a scriptless app ;-)).
At any rate, I don't see the need to dignify <prefix>/share and
friends with an official position.
> (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
> import sys ; sys.append(path-to-this-app's-python-lib)
> Or maybe "sys.insert(0, ...)".
Never really had to deal with this. On my RH box,
/usr/bin/python is my build. At a client site which had 1.4
installed, I built 1.5 into $HOME/bin with a hacked getpath.c.
> 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);
That's an artifact of your code ;-). If you figured it out once,
you stand at least a 50% chance of getting the same answer
a second time <.5 wink>.