> On Oct 29, 2014, at 11:37 AM, Steve Dower <steve.do...@microsoft.com> wrote: > > Antoine Pitrou wrote: >> On Wed, 29 Oct 2014 11:07:53 -0400 >> Tres Seaver <tsea...@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 _______________________________________________ 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
