This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lkcl
Recipients BreamoreBoy, LRN, WhiteTiger, amaury.forgeotdarc, davidfraser, eric.araujo, giampaolo.rodola, lkcl, rpetrov, rschoon.old, tarek, zooko
Date 2010-11-12.23:41:53
SpamBayes Score 2.88658e-14
Marked as misclassified No
Message-id <1289605314.24.0.0110028173196.issue3871@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2010-11-12 23:41:54lkclsetrecipients: + lkcl, zooko, amaury.forgeotdarc, davidfraser, giampaolo.rodola, tarek, eric.araujo, rpetrov, rschoon.old, WhiteTiger, BreamoreBoy, LRN
2010-11-12 23:41:54lkclsetmessageid: <1289605314.24.0.0110028173196.issue3871@psf.upfronthosting.co.za>
2010-11-12 23:41:53lkcllinkissue3871 messages
2010-11-12 23:41:53lkclcreate