[python-win32] Incomplete ZIP source files at sourceforge.net

[Mark Hammond]

> >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.