Supporting Python 3.7

[jakirkham]

Would be great to start testing and support Python 3.7.

[ukoethe]

Which compilers does c-f use for Python 3.7 on the three platforms? And while we are at it: which compiler are you using for Python 2.7 on Windows?

[jakirkham]

We are in the process of migrating to the same compilers that defaults uses for macOS and Linux. So this means Clang 4.0.1 on macOS and GCC 7.3.0 on Linux. We still support the system compiler we have been using as a legacy toolchain. Though this will likely be dropped once the migration is complete.

On Windows, we are using Visual Studio 2015 for Python 3.5+ (though Python 3.5 itself is being dropped currently).

With Python 2.7 conda-forge supports two options, Visual Studio 2008 or MSYS2's GCC 5.3.0. Currently not building VIGRA for Python 2.7 as the C++ requirements are not met by Visual Studio 2008 and AFAICT the dependency requirements are not met using the MSYS2 stack.

[ukoethe]

@emmenlau Do you know (or can you find out) how we can use Clang 4.0.1 in an azure MacOS-VM, as will be needed for Python 3.7 according to the above comment?

[jakirkham]

Should add packages that have been rebuilt are published to a separate label called gcc7 (this includes both the Clang 4.0.1 packages on macOS and GCC 7.3.0 packages on Linux). These will eventually graduate to the main label once the rebuild completes. Status on the rebuild can be seen on this page. We still have some ways to go, but some of the hard packages are done already.

All of VIGRA's dependencies should be satisfied; hence, we are working on rebuilding VIGRA with the new compilers in PR ( conda-forge/vigra-feedstock#43 ). Looks like one of the bugs you already fixed. ( #415 ) 😄

Also recently went through this change with a package of ours. If you use a conda-build recipe, it is as simple as adding this line.

[ukoethe]

published to a separate label called gcc7

We already use this label in our Linux builds on azure, because the main label did not work, IIRC. Didn't know that the gcc7 label also applies to macOS.

as simple as adding this line

 - {{ compiler("cxx") }}

What compiler will option cxx select, and which options are available?

[jakirkham]

Ah ok. Then you're ahead of the curve. 😄

By default, conda-build will look at this list. It this postfixes this with _{os}-{arch} (e.g. gxx on Linux becomes gxx_linux-64). One can override this list with variants in conda_build_config.yaml, which we do for the legacy compilers in conda-forge. One can also do this with a conda_build_config.yaml in the recipe directory itself or via a CLI option if there are different variants one would like to try. There's more details about the defaults compilers in this section (though other relevant information is on that page generally).

[jakirkham]

Looks like that patch was all we needed for Python 3.7 support.

Unfortunately we now have a segfault on macOS though.

Edit: This was caused by the static build of the Python interpreter and how we were linking things. See issue ( #458 ) for details.

[jakirkham]

Guess there isn't too much left to this. Adding the CI matrix cases would be good. Also addressing statically built Python interpreters ( #458 ) would be helpful.