[Distutils] Re: bdist_pkgtool attempt

[Greg Ward]

[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!!