> >What files are missing? What errors do you see? > > > The relevant files/directories from a diff output of the last three > releases:
All releases bar the last are of no real relevance (I'm not going to re-release them), but I believe you confirmed what I said about these previos releases. I believe you are also confirming that only the DirectSound files are missing from 204, and that one file has yet to be removed from CVS? > >pywin32 uses distutils to create the releases, including the > source archive. > >All this is managed in setup.py. As you pull from CVS, you > can create your > >own source distribution by running: > > > > setup.py sdist > > > Sure, I can do that, but if I have to do it, providing a source > distribution at sourceforge is useless. Sorry - I didn't meant you *should* do that - I meant you *could* do that if you wanted to assist me in refining this process. > If I can't be sure, that a source package has been tested > before it is > released, I always have the unpleasent feeling, that something is > missing or not up to date. I'm afraid I can't help with the unpleasant feelings :) All contributions towards a fool-proof, single-step process that does a clean build from the primary source tree for all supported Python versions, executes all tests (for all versions) and builds the .zip source archive (all versions again?) would be more than appreciated! Until such a process exists, I can do no more than apologize for any errors I make. > On my development machine, it requires only 5 minutes to do a > complete > build cycle (clean previous build, unpack, patch, build, create docs, > install), so what's the problem with testing that the packages builds > before you release it? Perhaps you would care to take over the release of these extensions? It certainly would help me to have someone else take care of the mechanics of the release process, and give me more time to work on the extensions themselves. If not, perhaps a contribution towards a single-step build process as mentioned that I can run? > Another point is, that some directoy names have an inconsistent case > style in the source distribution and in CVS: > In CVS, I find Pythonwin, com/win32comext/axdebug and > com/win32comext/axscript. > In the source distribution, I find pythonwin, com/win32comext/AXDebug > and com/win32comext/AXScript. > > I know, the Windows filesystems are case insensitive, but I'm > building a > Python runtime environment for Linux, AIX, HP-UX, IRIX and Windows. I > make all modifications and create patches on my Linux development > system. If there is a chance, to be a little bit more > consistent in case > style for directory/file names, it would make my live much > easier and it > would improve the readability of the sources. I have already explained the process of building the .zip distribution, and I'd be happy to receive patches that tweak this process so your life is easier. As a general rule, it takes more than one person complaining about some pedantic corner before I am inclined to spend alot of time worrying about it - but if you want to spend *your* time worrying about it (and only ask a little of my time in review and checkin), I'm generally happy to oblige. Mark. _______________________________________________ Python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
