[Tim]
the files where you want them after unpacking. What I upload will be an exact image of the build directory structure. Most feedback I've gotten is that people want exactly that, because they *want* to compile Python
[Barry Scott]
I'd not thought of that.
[Mark Hammond]
My either. I must admit mild surprise at that.
Not me, because this is the Python core: extension writers often have problems with their use of the Python C API, and the core is what supplies that. It's not surprising that they want to, e.g., drop some printfs into Python itself to see what's going on. Then they need to recompile Python. Plus that all the examples and instructions for building extensions assume you're working in a build-- not a release --tree.
If people want the debug files in the same tree as the build tree,
Some people, not all; by my informal count so far, "most", but it's like 2 or 3 to 1 -- and that's not only a ratio but a grand-total count.
it seems all they are trying to do is avoid the initial huge build. If they intend compiling, why are they asking for the binaries?
The "huge initial build" is no more than a few minutes, *provided* that they don't have to crawl over the web too to get source for, and figure out what to do with, the subprojects w/ a 3rd-party component (_tkinter, bsddb, pyexpat and zlib). Dealing with the latter for the first time can consume hours.
My experience with people wanting debug binaries is that they either don't want to, or can not build.
If they can't build, it's hard to take their claim to be developing extension modules seriously <wink>.
... For the last year or so, I have been making Debug builds of win32all available to registered users. This has always been made available in the "install" structure - quite a bit different than the source/build structure. I've never been asked for anything different.
Were you *asked* for even that much? Barry's was the first request Guido recalls ever getting. It sounded reasonable to me to supply *something*, so I did. But the download stats for this zip file suggest it's not popular enough to be worth arguing over. Still, I've gotten a little feedback on it, and most people seem to be happy. Not all developers want the same thing, and a flat .zip file with no internal directory structure is maximally flexible. If a handful of other Windows developers pop up who swear they can't live with a flat file, and can't bear to write a little Python or .bat script to move the files to where they want them, and swear they want some directory structure that's a fuzzy generalization of the Windows install structure, and swear they all want the same fuzzy generalization (e.g., where do they want the .pdb files? there are none in the install tree now), then, sure, I'll make the *other* peoples' lives a bit more difficult by default. I'm not going to ship two (or more!) of these things, though. view-it-as-a-chance-for-activestate-to-take-over<wink>-ly y'rs - tim