On 22 Nov 2013 02:03, "Chris Barker - NOAA Federal" <chris.bar...@noaa.gov> wrote: > > >> >> with older releases (I admit I don't understand the ABI compatibility on OSX). > > > Well, with OS-X, it's not exactly the C lic in the same way, but there are different SDKs for different OS versions, and you can add to that PPC vs Intel processors and 32 vs 64 bit. > > So we have for years had two builds for OS-X, and you can add to that Macports, Homebrew, and what have you. > > And the idea that this isn't an issue for gcc makes no sense-- it's such a big issue for Linux, in fact that python.org doesn't even try to build binaries for Linux, and pypi has disabled binary wheels for Linux.
Indeed :) For 2.7.7, I think some combination of the two following ideas would be worth pursuing: - a C runtime independent API flag (set by default on Windows when building with a compiler other than VS2008). This would largely be a backport of some of the stable ABI work from Python 3. - getting Windows closer to the current Mac OS X situation by ensuring that the C runtime used directly affects the ABI flags and shared library names. PyPI would apply the Mac OS X guideline where extensions are expected to be compatible with the python.org binaries. This would be the biggest change pushed through under the "make builds work" policy for the extended 2.7 lifecycle, but Microsoft's aggressive approach to deprecating old compilers and C runtimes means I think we don't have much choice. In the near term, if Stackless build to a different DLL name under VS2010 and make it clear to their users that extension compatibility issues are possible (or even likely) if they aren't rebuilt from source, then I think that would be compatible with the above proposal for a way forward. Then we'd just need some volunteers to write and implement a PEP or two :) (Note, similar to the Mac OS X situation, I think we should do this without hosting any new interpreter variants on python.org - VS2010 and VS2013 source builds would become separate build-from-source ecosystems for extensions, using sdists on PyPI as the default distribution mechanism) Cheers, Nick. > > >> >> So adding VS 2010 build files to the 2.7 tree would be fine with me, > > > I think this part is a no brainer. > > I also think having a 2.8 out there that is exactly the same as 2.7, except that it was built with a different version of a compiler on one particular platform is a very very bad idea. > > So how CAN this be addressed? This is really a distribution issue, and the distutils-sig has been hard at work building the infrastructure to support things like this. > > Right now, if you build binary wheels with the two different "official" OS-X builds, you will get two different names, and pop can find the correct one. (last I checked, pip would happily install the wrong one if you asked it to, though I think that is slated to be fixed) > > So if a different build of 2.7 for Windows is put out there, we need to make sure it reports the platform in a way that wheel and pip can make the distinction. > > It might be nice to patch the win_inst too--IIRC it's still not very smart about even 32 vs 64 bit builds. > > As for stackless--just to be clear--can you use extensions built with the "regular" python with a stack less binary? If so, I understand the concern. If not, then it seems stackless is a separate ecosystem anyway. > > Chris > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
