[Distutils] Re: bdist_pkgtool attempt
Tue Aug 29 21:50:01 2000
[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
[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
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,
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,
> 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 Ward - Unix nerd firstname.lastname@example.org
I have a VISION! It's a RANCID double-FISHWICH on an ENRICHED BUN!!