[Distutils] Re: [Python-Dev] Where to install non-code files

[Gordon McMillan]

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
> line:
>   import sys ; sys.append(path-to-this-app's-python-lib)
> 
> Or maybe "sys.insert(0, ...)".

$PYTHONSTARTUP ??

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>.
 


- Gordon