[Distutils] bdist_pkgtool attempt

Mark W. Alexander mwa@gate.net
Sun, 27 Aug 2000 22:47:36 -0400 (EDT)

On Sat, 26 Aug 2000, Greg Ward wrote:
> On 24 August 2000, Mark W. Alexander said:
> > As a first pass, it takes somewhat of a sledgehammer approach,
> > but it does work for at least a simple pure-python module.
> "Sledgehammer" is one way to put it.  It might be a more convincing
> translation if you finished the s/rpm/pkgtool/ job.  ;-)

Told ya so! I was only trying to convince myself that I could
do it without disrupting my production schedule. It's a
testimony to Mr. Gebel's rpm module (sp?) that I got it to work
without knowing poot about distutils.

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.

> The major problems I see with this adaptation are:
>   * reuse by cut and paste doesn't count.  I'm going to stop
>     accepting patches that just copy an existing module and
>     hack into shape... *now*.  If you want to implement
>     command bdist_foo, and it's very similar to bdist_bar,
>     then refactor first!

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 

>   * it shouldn't be the job of a shell script generated by
>     bdist_pkgtool.py to go from sys.prefix to
>     <prefix>/lib/pythonx.y/site-packages; that is already
>     done by the 'install' command when run with a certain
>     prefix.  Or you can use the 'get_python_lib()' function
>     from distutils.sysconfig.  Two places with this
>     logic are enough...

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. The script you're refering to is created
to be placed into the package to be run at "request" time,
where packages can ask the admin what to do. Instead of 
asking, the script figures it out by itself. This means that
with one pkgadd, I can install any number of modules with
no further intervention. Anyway, Using the standard package
install scripts to find python and automatically relocate is 
best of several poor solutions. If you've got a better idea,
I'll take it.

> 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. And, since most
my sysadmin scripts are in Python, being able to effortlessly
maintain package modules for both is why I need distutils. If
it was just rpm, I could manage without.

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

And I DON'T mean now as in "drop everything, this is important,
I gotta get it done", either, cause the time I have to devote 
is pretty slim anyway. That's the biggest reason I wanted to
post something, so that maybe someone else would be interested.
That, and I think I promised to do it sometime last year(?)...
Unfortunately, from what I've seen on this list I'm the lonely
Solaris/HP repairman. So, what I did will hold me for a while.

And finally, the reason I'm suddenly pushed to get things 
packaged and out the door is because I've finally got some
help to start dumping on^W^W training. I would like to note
for the record, that without distutils I'd have spent at least
days, probably weeks, getting things organized, packaged, and 
prepared for moving to 1.6 on all my platforms. Your work is
really paying off, and it is most sincerely appreciated!

Mark Alexander