[Python-Dev] Status of C compilers for Python on Windows

[Donald Stufft]

> On Oct 29, 2014, at 11:37 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> 
> Antoine Pitrou wrote:
>> On Wed, 29 Oct 2014 11:07:53 -0400
>> Tres Seaver <tseaver at palladion.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> On 10/29/2014 10:31 AM, R. David Murray wrote:
>>> 
>>>> If you are writing code targeted for Windows, I think you are very 
>>>> likely to have an MSDN subscription of some sort if your package 
>>>> includes C code.  I'm sure it's not 100%, though.
>>> 
>>> My experience with distributing distributions-with-extensions 
>>> indicates that the vast majority of Windows developers who are 
>>> "downstream" users for those distributions *cannot* build them from 
>>> source:  if there is no MSI / bdist_win (maybe now wheel), they won't use the project.
>>> 
>>> (Note that "having an MSDN subscription" is not the same as "knowing 
>>> how to configure which compiler such that it can bulid extensions 
>>> against an installed Python binary").
>> 
>> I don't think you have to configure anything. Just install the right Visual Studio version and it's done.
> 
> The tricky part here is the *right* Visual Studio version. As many have noted, there were bugs/missing components in some of the older Express editions (like the 64-bit compiler integration), and even the compiler pack we released recently doesn't actually help building Python itself, though it's good for extensions. In general, VS 2008 Professional and VS 2010 Professional are easiest to set up if you can get them, the C++ Express editions are fairly easy to set up, and the Windows SDK is difficult but possible (and won't currently build CPython either, as the build depends on VS - I'm also fixing this for 3.5).
> 
> My ideal target (Utopia refined to be achievable) is for python-dev to handle the Python binaries themselves (already done) and to make them easy to bundle with applications/etc (I'm working on this for 3.5), and for PyPI to include pre-built wheels for Windows where necessary.
> 
> Note that I don't require package developers to build their own wheels, though I think that they are generally the right people to be doing it. It would be nice to create a culture of delegation, so that "someone" could be a trusted builder for a range of packages (for example, I'd love it if Continuum/Enthought/similar could provide their builds of numpy/scipy as wheels and those projects would be willing to have them be the official PyPI downloads). This is roughly how the python.org installers are handled, and while it may cause some lag between source and binary releases, I think the release cycles are slow enough that most users would only notice that "pip install numpy" now works.

For the record, a long term “down the road” kind of thing I want to do is have PyPI have a build farm which can build Wheels. So that people upload a source distribution to PyPI and it kicks off Wheel builds on the various platforms automatically.

What this looks like is a complete unknown, all I have is the general idea.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA