[quoth Mark Alexander]

SD-UX is Software Distributor for HP-UX. I have the same problem with the 'd'. I'm not attached to the name, so _hpux or _depot (that's what an hp package is called) or even just _hp. I'm just not positive that HP is the only one that uses this format.

Then "bdist_sdux" is the right name. There are already approximately 17,000 known installation tools and/or schemes named "depot"; why confused matters? [my loopy idea]

Ahh, gotcha. Idea: don't use Distutils to do the install, but do take advantage of it for the install-time scripts. Or rather, take advantage of Python and assume that the Distutils are installed on the target machine. Then you can do

from distutils.sysconfig import get_python_inc

libdir = get_python_lib(plat_specific=1) ...

instead of that nasty shell trickery-pokery.

[Mark responds skeptically]

Hmm, so I would then invoke distutils 'install' and force it to that directory? Then I'd either have to force the file inventory somehow

Or just use the Distutils' handy tools for copying files around; see distutils.dir_util.copy_tree(). That's what the "install" command uses. Most of the distutils.*_util modules are intended to make writing shell-style code in Python relatively simple. (Then will someone please explain to me why the Distutils is 6,300+ lines of code... sigh... another great idea shot down by cold, hard reality.)

I tend to favor letting the native tool do as much as possible, though.

Definitely. If "native tools" means including shell code in your installer rather than Python code, so be it. It *is* icky to have the "prefix + lib/pythonX.Y/site-packages" knowledge in 3 places, though... 2 (sysconfig.py and install.py) is bad enough, but just because I slipped up doesn't mean we should let things get worse.

My assumption is that if you're building binaries, your doing it for people who don't care about distutils or anything else about how the binary was created. They just want it to work like everything else they do.

Umm, if they want everything to "just work", what on earth are they still using Solaris for? (Note the total absence of a smiley here: I'm dead serious! I used to think Linux was "just another Unix", so adjusting to Solaris at work wouldn't be so bad. I guess I didn't stop to think about what an enormous difference it makes to have "less" installed out-of-the-box... never mind Emacs, GCC, KDE, Gnome, Gtk, Qt, etc. etc.)

This assumption is too painfull for me. When I assumed my current position, I took over dozens of archaic machines where the disks where sliced horribly. Of course, I HAD to have python everywhere, so I built packages that relocated (and linked to /usr/bin and /usr/local/bin). Because of that experience, I've become a fanatic advocate of relocatable packages.

Ooh, that reminds me: need to check in to the relocatability of Distutils-generated RPMs. This is not a concern for "dumb" built distributions (they *are* dumb, after all), but I see no good reason why our RPMs (and other "smart" distributions) shouldn't at least be relocatable at user preference. (Note that I'm drawing a distinction between "relocatable" -- user specifies the installation prefix -- and "smart enough to figure out where Python is installed, and put itself there". I still don't consider the latter essential for RPMs, but I do for Windows installers. Go figure. Anyone else care either way?) Greg -- Greg Ward - Unix nerd gward@python.net http://starship.python.net/~gward/ I have a VISION! It's a RANCID double-FISHWICH on an ENRICHED BUN!!