[SciPy-Dev] win32 binaries and scipy 0.17.0 release

[josef.pktd at gmail.com]

On Sat, Jan 2, 2016 at 2:13 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi Josef,
>
> On Sat, Jan 2, 2016 at 5:51 PM,  <josef.pktd at gmail.com> wrote:
>> On Sat, Jan 2, 2016 at 12:30 PM, Tony Kelman <tony at kelman.net> wrote:
>>> Matthew Brett <matthew.brett <at> gmail.com> writes:
>>>
>>>> It would certainly be useful to share effort or at least discussion about
>>> this.
>>>>
>>>> Are there any good places to go to understand the logic behind
>>>> upstream Python's lack of interest in these patches / mingw-w64 Python
>>>> generally?  I'd love to hear how you are dealing with DLL hell and pip
>>>> on the msys2 system...
>>>
>>> I think the last time this was discussed was in the October 2014
>>> python-dev thread "Status of C compilers for windows"
>>> https://mail.python.org/pipermail/python-dev/2014-October/136607.html
>>> My personal conclusion from that was it could be cleaner to turn
>>> MSYS2's large patch set into a formal fork that anyone could build
>>> (or cross compile) even if not using MSYS2's pkgbuild system, but I
>>> didn't get too far there.
>>>
>>> My understanding of how the MSYS2 python works is that for pure
>>> python modules without C extensions, pip should work fine. There
>>> are issues with virtualenv last time I checked, and I don't know
>>> how careful the MSYS2 packagers are about checking the status of the
>>> test suites of all their C extension builds. If you get all C
>>> extensions from MSYS2 then there is no dll hell, but mixing C
>>> runtimes can of course cause problems. Some of their patches are
>>> in distutils to also make that recognize and use mingw-w64 compilers,
>>> but that would need some firsthand testing to see how well it works
>>> on C extension modules that haven't been packaged by MSYS2 yet.
>>>
>>> To be clear I think the current approach of trying to make mingwpy
>>> more robust and eventually get it upstreamed makes sense. But you're
>>> forking GCC with features (linking against recent msvc runtimes)
>>> upstream mingw-w64 doesn't want to use, as MSYS2 is forking cpython
>>> with features upstream python-dev doesn't want. It's kind of
>>> unfortunate all around.
>>
>>
>> A general question about what I don't understand in this discussion.
>>
>> What are the incompatibilities of mingwpy compiled C extensions with
>> the official PSF python versions?
>>
>> I have been using MingW compiled statsmodels forever, and MingW64 for
>> maybe two years up to python 3.4 and never ran into problems.
>> I'm using now almost exclusively Winpython and the packaged gcc, which
>> seems to come with all required local DLLs.
>>
>> (I thought the main or only problems are DLL packaging and Fortran.)
>
> There's a fairly detailed summary of the issues over at
> http://mingwpy.github.io/issues.html


Thanks for the link.

Sounds like something for the experts, and not something I have to
worry about myself.
(except maybe that I will never again add a new 32 bit python install.)

Josef


>
> Cheers,
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev