[Distutils] bdist_pkgtool attempt
Mon, 28 Aug 2000 21:31:43 -0400
On 27 August 2000, Mark W. Alexander said:
> And by finish you mean "finish destroying Mr. Gebel's code"?
> I don't think so....When I get back to it, it will be to do
> it right.
> No problem. For me, this was jump in, get my feet wet and see if
> I could make it work. bdist_sdux is better in that at least I
> understood the steps. My first priority is to package a bunch
> of local mods, and this has got that licked. I'm more than happy
> to take advice on the distutils way and improve it as time
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"...
> The problem with that is that you either A) get the info at
> build time or B) run distutils to do the actual binary install
> on the target. In my case, A is not a reliable indicator of
> where python is installed on the target machine. B loses the
> advantage of the native packager in that the file inventory
> is not registered.
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.
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... ;-)
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. ;-)
> > Oh, and of course I have a burning and irrational hatred of Solaris
> > which, unlike my burning and irrational hatred of Windows, stems from
> > actual use. So the idea of lifting a finger to help Sun, even as
> > indirectly as this, really sticks in my craw. >grin<
> There's nothing irrational about it;-) But, distutils really needs
> to support it, along with the other big unnamed ones. Having
> to work on Solaris and HP are bad enough, but to do so without
> Python is simply cruel and unusual punishment.
Yeah, you're right; no point in punishing the poor hapless souls stuck
with the evil spawn of Sun. My sympathies.
> So...don't help Sun, help me and others like me. First, forget
> this one, I'll clean it up later. Give me constuctive
> criticism on bdist_sdux (which has a completely different
> relocation nightmare) and I'll retrofit the advice to
> pgktool. At the very least, point me to some description
> of the inputs to the bdist_XXX modules and the setup
> and use of bdist module options. I mean, if you want
> quality bdist_modules, you need to give quality
What, the source code isn't documentation enough? ;-)
Well, Fred has been pushing me to write some "Distutils Internals"
documentation. Back to the docs...
Greg Ward - Unix geek firstname.lastname@example.org
Very few profundities can be expressed in less than 80 characters.