[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4