[Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

[Robert McGibbon]

Got it. Thanks, Nathaniel -- this is really good information.

-Robert

On Mon, Oct 19, 2015 at 6:55 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Mon, Oct 19, 2015 at 2:26 AM, Olivier Grisel
> <olivier.grisel at ensta.org> wrote:
> >> Is it possible to test this with py35 as well?
> >
> > Unfortunately not yet.
> >
> >> For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that
> >> something mingwpy/mingw-w64 can handle?
> >
> > I am pretty sure that mingwpy does not support Python 3.5 yet.
>
> Correct.
>
> > I don't know the status of the interop of mingw-w64 w.r.t. VS2015 but as
> far
> > as I know it's not supported yet either. Once the issue is fixed at the
> > upstream level, I think mingwpy could be rebuilt to benefit from the fix.
>
> Upstream mingw-w64 doesn't support interop with any version of visual
> studio that was released this millennium -- all the interop stuff is
> new in mingwpy.
>
> VS2015 had a major reorganization of how it handles runtime libraries,
> so it's not quite so trivial as just adding support the same way as
> was done for VS2008 and VS2010. Or rather, IIUC: we *could* just add
> support the same way as before, but there are undocumented rules about
> which parts of the new runtime are considered stable and which are
> not, so if we did this willy-nilly then we might end up using some of
> the "unstable" parts. And then in 2017 the Windows team does some
> internal refactoring and pushes it out through windows update and
> suddenly NumPy / R / Julia / git / ... all start segfaulting at
> startup on Windows, which would be a disaster from everyone's point of
> view. We've pointed this out to the Python team at Microsoft and
> they've promised to try and put Carl and the relevant mingw-w64 folks
> in touch with the relevant internal folks at MS to hopefully tell us
> how to do this correctly... fingers crossed :-).
>
> Aside from that, the main challenge for mingwpy in general is exactly
> the issue of upstream support: if we don't get the interop stuff
> pushed upstream from mingwpy to mingw-w64, then it will rot and break.
> And upstream would love to have this interoperability as an officially
> supported feature... but upstream doesn't consider what we have right
> now to be maintainable, so they won't take it as is. (And honestly,
> this is a reasonable opinion.) So what I've been trying to do is to
> scrounge up some funding to support Carl and upstream doing this right
> (the rough estimate is ~3 person-months of work).
>
> The original goal was to get MS to pay for this, on the theory that
> they should be cleaning up their own messes, but after 6 months of
> back-and-forth we've pretty much given up on that at this point, and
> I'm in the process of emailing everyone I can think of who might be
> convinced to donate some money to the cause. Maybe we should have a
> kickstarter or something, I dunno :-).
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151022/673badda/attachment.html>