enable Python 3.5 Windows build

[Cadair]

This will presumeably break.

[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.

[Cadair]

ping @ocefpaf from conda-forge/staged-recipes#605

[ocefpaf]

Thanks for opening the issue. Here is the full log. I will take a look at this once I get back to my office.

===== testing package: glymur-0.8.3-py35_0 =====
import: 'glymur'
C:\conda\envs\_test\lib\site-packages\glymur\lib\config.py:151: UserWarning: Neither the openjp2 nor the openjpeg library could be loaded.  
  warnings.warn(msg)
Traceback (most recent call last):
  File "C:\conda\conda-bld\test-tmp_dir\run_test.py", line 26, in <module>
    import glymur
  File "C:\conda\envs\_test\lib\site-packages\glymur\__init__.py", line 5, in <module>
    from glymur import version
  File "C:\conda\envs\_test\lib\site-packages\glymur\version.py", line 17, in <module>
    from .lib import openjpeg as opj, openjp2 as opj2
  File "C:\conda\envs\_test\lib\site-packages\glymur\lib\__init__.py", line 4, in <module>
    from . import c
  File "C:\conda\envs\_test\lib\site-packages\glymur\lib\c.py", line 9, in <module>
    C_LIB = ctypes.CDLL(LIBC_PATH)
  File "C:\conda\envs\_test\lib\ctypes\__init__.py", line 347, in __init__
    self._handle = _dlopen(self._name, mode)
TypeError: bad argument type for built-in operation
TESTS FAILED: glymur-0.8.3-py35_0

[Cadair]

ping @quintusdias do you have any ideas on this?

[quintusdias]

That is the first time I've seen that failure. Might be possible to avoid
it altogether though. The only reason I put glymur.lib.c together in the
first place is that the openjpeg 2.0 API requires raw file pointers. The
2.1 API does not. There are enough bugs in 2.0 that are fixed in 2.1 that
it might make sense to just drop 2.0 compatibility. Boom, no more need for
glymur.lib.c

On Wed, May 18, 2016 at 9:47 AM, Stuart Mumford notifications@github.com
wrote:

ping @quintusdias https://github.com/quintusdias do you have any ideas
on this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1 (comment)

John Evans

[Cadair]

well conda-forge build 2.1 so I am happy to not support 2.0.

Is this error it trying to find the openjpeg C library?

[Cadair]

so not that then. Unless it's not finding the conda package version of openjpeg correctly.

[quintusdias]

Nope, it's failing to find the MS standard C library. Which is kind of
odd/aggravating.

OpenJPEG's been pretty quiet on the development front lately, so I haven't
felt the need to match it with development on glymur. I'll look to see if
I can't throw together an 0.8.4 release, though.

On Thu, May 19, 2016 at 5:47 AM, Stuart Mumford notifications@github.com
wrote:

so not that then. Unless it's not finding the conda package version of
openjpeg correctly.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1 (comment)

John Evans

[quintusdias]

and actually, as I look again at the code, the reason it's failing to find
the MS standard C library is that it must be misidentifying the platform.
The relevant code is

if sys.platform == 'win32':
C_LIB = ctypes.windll.msvcrt
else:
LIBC_PATH = ctypes.util.find_library('c')
C_LIB = ctypes.CDLL(LIBC_PATH) # <---- failure

So, it's taking the wrong code path. Which means that sys.platform isn't
'win32' in this case?

On Thu, May 19, 2016 at 5:57 AM, John Evans john.g.evans.ne@gmail.com
wrote:

Nope, it's failing to find the MS standard C library. Which is kind of
odd/aggravating.

OpenJPEG's been pretty quiet on the development front lately, so I haven't
felt the need to match it with development on glymur. I'll look to see if
I can't throw together an 0.8.4 release, though.

On Thu, May 19, 2016 at 5:47 AM, Stuart Mumford notifications@github.com
wrote:

so not that then. Unless it's not finding the conda package version of
openjpeg correctly.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1 (comment)

John Evans

John Evans

[quintusdias]

Sorry, hold on again. In my previous, I had been looking at my devel
branch for glymur, and there's a commit dating from last december (after
0.8.3 was released) that introduced that code path, so that code in my
previous might be the fix that's needed. Which would mean that glymur
might have been broken on windows for 0.8.3.

Will still look at an 0.8.4 release (and make sure it works on windows).

On Thu, May 19, 2016 at 6:04 AM, John Evans john.g.evans.ne@gmail.com
wrote:

and actually, as I look again at the code, the reason it's failing to find
the MS standard C library is that it must be misidentifying the platform.
The relevant code is

if sys.platform == 'win32':
C_LIB = ctypes.windll.msvcrt
else:
LIBC_PATH = ctypes.util.find_library('c')
C_LIB = ctypes.CDLL(LIBC_PATH) # <---- failure

So, it's taking the wrong code path. Which means that sys.platform isn't
'win32' in this case?

On Thu, May 19, 2016 at 5:57 AM, John Evans john.g.evans.ne@gmail.com
wrote:

Nope, it's failing to find the MS standard C library. Which is kind of
odd/aggravating.

OpenJPEG's been pretty quiet on the development front lately, so I
haven't felt the need to match it with development on glymur. I'll look to
see if I can't throw together an 0.8.4 release, though.

On Thu, May 19, 2016 at 5:47 AM, Stuart Mumford <notifications@github.com

wrote:

so not that then. Unless it's not finding the conda package version of
openjpeg correctly.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1 (comment)

John Evans

John Evans

John Evans

[Cadair]

@quintusdias We are looking at doing a SunPy release with Python 3 support for the first time this week or early next week, so if you could get 0.8.4 out of the door as soon as you have some time that would be great.