[Distutils] bdist_pkgtool attempt

[Mark W. Alexander]

On Mon, 28 Aug 2000, Greg Ward wrote:
> OK, good, one more budding Distutils hacker with feet wet.  Excellent!
> Need all the help we can get.
> 
> I will take a closer look at bdist_sdux; I was worried that it would be
> a hatchet job similar to bdist_pkgtool, and I hate reading cut 'n pasted
> code.  But first, you have to tell me what "sdux" stands for.  I keep
> mentally dropping the "d"...

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.

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

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. I'm not aware of a clean way to do that, although the
inventory files are text that could be manipulated. I tend to
favor letting the native tool do as much as possible, though.
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. Maybe I've just been around too many
people who prefer ignorance....

> Of course, you may have a slight chicken/egg problem in getting the
> Distutils installed, if these target platforms are running 1.5.2.  Umm,
> left as an exercise for the reader... ;-)

I can cope. The package can be made dependent on python 1.6. If 
necessary, I can provide python binary packages for Solaris and 
HP and submit them to the usual sites. As long as the package
criteria is known, making dependencies is a breeze.

> Note that the other Unix bdist_* commands (dumb and rpm, at this date)
> don't do anything smart about install location.  They just mimic
> whatever the structure on the build host was.  This is just fine for
> bdist_rpm; if you're building and RPM for Red Hat 6.2, you should be
> doing so with the Red Hat 6.2 Python interpreter.  For bdist_dumb, it's
> just laziness on my part -- and the only real way to deal with the
> potential prefix/exec-prefix distinction.
> 
> General principle: when writing a bdist_* command, I won't bite your
> head off if you assume that the target system's Python installation is
> the same as the build system's.  At least for Unix: I think on Windows,
> it's important to adjust to the user's preferred location for Python.
> Probably the same for Mac OS... someday.  ;-)

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. If the installer doesn't
care, then default directories are fine. If they have any need to
be creative (like building an NFS utility partition) I don't
feel it's a packager's place to cripple them. Making packages
relocatable is not that difficult (even though making packages
that make relocatable packages can twist your brain....).

> Yeah, you're right; no point in punishing the poor hapless souls stuck
> with the evil spawn of Sun.  My sympathies.

Thanx B-\

> What, the source code isn't documentation enough?  ;-)

Usually, yes. I must have looked at the Command class for at least 5
minutes before trying sdux! Time is just too short for me right now.

> Well, Fred has been pushing me to write some "Distutils Internals"
> documentation.  Back to the docs...

I did see you mention somewhere that there was some docs in CVS.
I have had problems getting the CVS version since I'm behind a
firewall. If there's something there that's helpfull, I'd appreciate
it included in the next snapshot (or even a seperate doc-only
snapshot). But rather than "Distutils Internals", may I recommend
a "command writer's guide" first? My impression is that Distutils
is both robust and enough for 1.0 and that those already involved
are probably knowledgable enough to squash bugs. The biggest are
for improvement now lies in additional package format support.
And let's face it, making packages ain't brain surgery. If I
can make a bdist_pkgtool_sux_but_works in a couple hours
by stepping through someone elses bdist and typing over lines, it
can't require that much knowledge of distutils internals.
Actually, I'm now just sorry I didn't make the attempt a long
time ago.  Once I get the hang of it, I'd even be willing to
install debian somewhere to try _deb if no one else has
committed to it. (But do NOT ask me to do AIX!)

mwa