15.3.0, bundle zeromq on Windows + py35

[minrk]

includes import check on Windows, which would have caught the fact that our win+py35 package doesn't import

import check was already there, so I'm not sure how any previous build on py35 ever succeeded.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

It looks like this is getting imported on all platforms above. Or am I missing something?

[minrk]

You are absolutely right. I'm not sure why this is broken, then, because downstream packages are failing to build on win+py35 because they can't import zmq.

conda-forge/ipyleaflet-feedstock#6

If this ran before, I'm not sure what could be causing it to fail now. I just saw that the only failing case was win+py35 and that happens to also be a special-cased build here, so I figured it must be the culprit.

[jakirkham]

FWIW I think the other changes proposed here look reasonable. If there is something off about the Windows Python 3.5 build, then we should drop the special casing of it. I'm just not sure the best way to test it.

It could be that there is something that changed about zeromq that doesn't work. Let's take a look at that.

[jakirkham]

That's right. We don't build zeromq for Windows at conda-forge. Yeah, I'm ok to go ahead with this. Maybe there is something that changed about the defaults copy of zeromq.

[jakirkham]

Well, it looks like the same zeromq version and build number in the last successful build here and the failure in ipyleaflet. We did update the vs2015_runtime version yesterday. Maybe that is to blame?

[jakirkham]

LGTM

[jakirkham]

Interesting. This failed on Windows Python 3.5 64-bit only. See this log.

win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.5\Release\buildutils\libsodium.cp35-win_amd64.lib
initlibsodium.obj : warning LNK4197: export 'PyInit_libsodium' specified multiple times; using first specification
   Creating library build\temp.win-amd64-3.5\Release\buildutils\libsodium.cp35-win_amd64.lib and object build\temp.win-amd64-3.5\Release\buildutils\libsodium.cp35-win_amd64.exp
Generating code
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\amd64\\link.exe' failed with exit status 1

[minrk]

Yeah, I saw that and hoped it was temporary, so poked AppVeyor but it happened again. I have no idea what could cause that. It's remarkably uninformative.

[bollwyvl]

I'm also seeing the same fail locally with the vagrant box @msarahan suggested:

ContinuumIO/vagrant-images#1

Also, isn't it a bit odd that the 3.5 builds are not pulling in vs2015_runtime?

By the by, I've found the tests can actually be (mostly) run on windows with:

commands:
    - nosetests zmq.tests  # [not win]
    - start /b /wait %comspec% /c nosetests zmq.tests -I test_win32_shim.py  # [win]

bad to be skipping win specific stuff, but good to be running the 184 tests...

[jakirkham]

You're absolutely right AFAICT, @bollwyvl. It appears to be the same with Python 3.4 as well. Both of which conda-forge packages now. Not the case with Python 2.7 though (not packaged by conda-forge yet). In any event, I raised this issue ( conda-forge/python-feedstock#47 ) to see if there is a reason for these being missing. We can figure out how to go from there.

[SylvainCorlay]

In the mean time, I think that it would be nice removing the broken windows build from the channel since pyzmq is a pretty common dependency.

Regarding the dependency to the MSVC2015 runtime, it should not be needed for versions earlier than 3.5 except if we forced the build with MSVC2015 regardless of the python version.

[jakirkham]

So Python 3.5 at conda-forge now includes the VS runtime. This can be verified in the 64-bit package and 32-bit package. As a result, I think we can drop this.

[minrk]

I thought this was the cause of the recent failures, but it doesn't appear to be. Removed, and we'll see how it goes!

What would happen if a user got Python 3.5 from defaults? Would they still get vs2015_runtime?

[jakirkham]

We hadn't been including it before. I think I agree that it may have been causing issues. So, I asked if we could add it in this issue ( conda-forge/python-feedstock#47 ). It was proposed for addition, accepted, and built as part of PR ( conda-forge/python-feedstock#51 ). We did the same thing for Python 3.4 in PR ( conda-forge/python-feedstock#52 ). There were some other useful Windows patches that were added too. Hopefully these changes help.

Yes, a user would get vs2015_runtime with Python 3.5 on defaults. Now we are doing the same thing.

[jakirkham]

I know we don't build for other Python 2.x versions, but could we please change py27 to py2k. This could be useful for people building offline with older Python 2.x offline.

[minrk]

Good catch. Done.

[minrk]

cf conda/conda-build#1146 for a patch to conda-build that would make this unnecessary

[jakirkham]

Yeah, I really don't understand why conda-build has that behavior at all. It seems more trouble than it is worth. There are other cases it struggles with like templated Python code.

[minrk]

It works!

[minrk]

I couldn't get the 14.7 build to succeed on 64b Windows + cp35 for reasons I still don't understand, but after bumping to 15.3, all appears to be well.

[jakirkham]

Given you are the author of pyzmq and some other things depending on it, is there any sort of breakage for downstream packages that we need to be aware of or mitigate somehow (e.g. version pinning)?

[minrk]

The only backward-incompatbile change in 15.x is the fact that it will ignore system libzmq < 3 when it's deciding whether to bundle libzmq or use the one it found on the system. It isn't relevant to the conda package.

[jakirkham]

Thanks for clarifying. LGTM

[jakirkham]

Everyone else happy with this change?

[msarahan]

Thanks all.