Luke Kenneth Casson Leighton <l...@lkcl.net> added the comment:

erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: 
there really is no other way, as you can see from the previous walkthrough 
analysis, and is reinforced by the further analysis below.

simply put: if the freeze on distutils is not lifted, then this entire set of 
work, which has been going on for years and _precedes_ the distutils freeze by 
at least 18 months, is completely, utterly and totally wasted.

let's walk through the situation where distutils2 is forced to be used.

what you're asking for is, basically, that every single third party package, of 
which there must be tens of thousands, must be patched for compilation on 
mingw32... _just_ so that it says "if sys.platform == 'mingw32': from 
distutils2.core import setup else: from distutils.core import setup", is that 
correct?

does that strike you as being completely and utterly unreasonable an 
expectation, to ask third parties to modify setup.py scripts which have worked 
perfectly well for years, many of which are likely to no longer even have a 
maintainer?

that leaves patching - which should be nothing more than _adding_ to - not 
"changing existing compilers" - ADDING an extra compiler - distutils as the 
only option.

now, that can be done monkey-patch style (i.e. at runtime, by adding in code 
very early on in python startup, or perhaps by patching the import system to 
replace the word "distutils" with "distutilsmingw32") or it can be done... by 
lifting the distutils freeze.

perhaps i should ask: what _exactly_ is the problem, and why do several teams 
complete and utter failure to do the correct thing by making changes to 
_existing_ compile platforms have anything to do with _this_ team's patches 
which add a new totally separate platform that has absolutely nothing to do 
with any of the other platforms?

i could say more, but i believe the point is clear: none of the people involved 
in seeing mingw32 added as a platform had _anything_ to do with the past 
failures, so why "punish" and mis-trust the python-mingw32 for other peoples' 
failures?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to