Luke Kenneth Casson Leighton <[email protected]> added the comment:
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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue3871>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
