[Python-Dev] Re: [Distutils] Questions about distutils strategy

[Tim Peters]

[Guido]
> [Great analysis, Tim!]

I beg to differ:  it's internally inconsistent and should have identified at
least 3 axes and hence at least 8 cases.  Still, you got more than you paid
for <wink>.

>> 4) The audience is Python end-users "in general", and the
>> product is pure Python.  I think this is the most important one
>> for Distutils to address, and compilation isn't a part of it.
>> So far, though, what Gordon is doing seems more appropriate
>> than what Distutils has been up to.  I hope his work gets folded
>> into this.

> I'm not sure what stuff by which Gordon you're referring to.

You guessed right!

> I am only familiar with his installer, which I thought is win32
> only (but I may be mistaken) and is an installer for a whole
> application, not just a bunch of modules.  Please correct me if
> I'm wrong.

If it can install a whole app, what makes you suspect it couldn't install
just a bunch of modules <0.5 wink>?

It started life as Windows-only, and I believe it's been virtually ignored
by non-Windows folk because of that.  Bad blind spot.  It supplies
already-working approaches to many of the issues that are still being
*talked* about on Distutils (at least archive formats, code to manipulate
same, manifest files (how do you tell the tool which files to package?), and
transparently bundling a Python interpreter when needed).

> But this reminds me of a different issue, which Jim Ahlstrom has
> been hammering about before: there's a completely separate set of
> cases where what you are distributing is a stand-alone application,
> and the target consists of end users who are entirely uninterested
> in whether it's written in Python, C or Elvish.

I include part of that in my case #4 above, where the app happens to be
written in Pure Python -- but the user doesn't have to know that.  Gordon is
addressing at least that part of it.  AFAIK he can't deal with transparently
compiling C or exorcising Elvish on the target platform, but if you're just
distributing the binaries I expect his work is directly usable already.

> (And then there's still the distinction between Win32, Unix or
> both.)

I vote "both".  The world really doesn't need another Win32-only (or
Unix-only) installer, archive format, compression format, or distribution
model.

Jim seems mostly interested in Win32-only to me, and his concerns haven't
been about the mechanics of distribution but about how-- regardless of
tool --to create a bulletproof Python installation by hook or by crook.
Last time we went thru this, it was concluded that one couldn't without
patching the Python Windows binary with a resource editor (to point to its
own infernal <0.5 wink> registry entries).

Distutils hasn't talked about that at all (that I've seen, anyway); if there
were a less radical approach to that, I suspect Jim would be delighted to
use one of the commercial Win32 installation pkgs (and if that's what his
customers expect, delighted or not that's what he'll do).

> The current distutil dools don't deal with this at all.

That's why I said I thought what Gordon is doing seems more appropriate to
case #4 than what Distutils has been doing.

> I think it should though,

Ditto.

> and I think its framework is powerful enough to be able to
> add this, e.g. as a new "appdist" command.

I cordially invite (since Gordon will uncordially browbeat <wink>) people to
look seriously at what he's done.  Best I can tell, for apps that don't need
compilation "on the other end", it's mostly "there" already!

give-the-man-a-hand-ly y'rs  - tim