[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