sorry to have to ask, but could we get some feedback please so that this issue may move forward?  currently there is a conflict between what is required and what is stated as being "absolute law".

let's imagine that it is reasonable to expect distutils2 to be used.  python proceeds with the mingw32 patches using distutils2, python 2.N is compiled and released.  an average user installs python 2.N mingw32 and they run "python setup.py install" on a package - what happens?

they get a compile error, don't they?

why do they get a compile error?

because the setup.py tries to build some c code, and at the top of *their* setup.py is "import distutils".

so you now force thousands of developers to patch allll their setup.py scripts - scripts which have worked for years - _just_ so that those packages can cope with the use of distutils2 for the mingw32 platform?

so we have another "reducto ad absurdum" which demonstrates that it is impractical to expect distutils to be frozen.

thus, we are forced to consider alternative options, such as "monkey-patching" of distutils, to satisfy the requirements.

would the following be acceptable, to be inserted somewhere in the path so that it is guaranteed to work at all times?

import mingw32_distutils_compiler
import sys
if "distutils.compiler" in sys.modules:
    sys.modules['distutils.compiler'] = mingw32_distutils_compiler


where mingw32_distutils_compiler performs an import of distutils.compiler and performs a monkey-patch mish-mash to combine and replace various parts of the compiler module at run-time, to get round the "freeze" objections.

would that be acceptable?  please say no, because the long-term viability and maintainability of such practices is virtually nil.

basically i'm pointing out to you, eric, that the freeze on distutils is unworkable and impractical and unnecessary.

this isn't "bug-fixing" of distutils, it's absolutely necessary and critically required because this is an entirely new platform.

* it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks.

* it's not standard unix gcc: you need to output ".dll" not ".so"

* it's not msvc: mingw32-gcc doesn't accept "/this /that" for options.

therefore i'm very sorry to have to spell it out but a new compiler and linker type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type - IS required in order to cater for this platform, and there's no getting away from that fact.

please could we have some acknowledgement of this fact, and acceptance of this fact, and a plan for moving forward with careful review of this patch, so that LRN and others do not have their time spent pursuing a direction involving distutils2 which will be completely fruitless?

many many thanks,

l.