Fiona: Windows CI

[rbuffat]

A Windows CI could be useful to test Fionas behavior on windows platform or in the future to build binary wheels for windows.

I started playing with appveyor: https://github.com/rbuffat/Fiona/blob/win/appveyor.yml, respectively: https://ci.appveyor.com/project/rbuffat/fiona @micahcochran the current status is that fiona can built but at runtime the following error is thrown:

Traceback (most recent call last):
File "c:\python27.10-x64\lib\site-packages\nose\suite.py", line 209, in run
    self.setUp()
File "c:\python27.10-x64\lib\site-packages\nose\suite.py", line 292, in setUp
    self.setupContext(ancestor)
File "c:\python27.10-x64\lib\site-packages\nose\suite.py", line 315, in setupContext
    try_run(context, names)
File "c:\python27.10-x64\lib\site-packages\nose\util.py", line 471, in try_run
    return func()
File "C:\projects\fiona\tests\__init__.py", line 39, in setup
    create_jsonfile(jsonfile)
File "C:\projects\fiona\tests\__init__.py", line 20, in create_jsonfile
    import fiona
File "build\bdist.win-amd64\egg\fiona\__init__.py", line 72, in <module>
File "build\bdist.win-amd64\egg\fiona\collection.py", line 7, in <module>
File "build\bdist.win-amd64\egg\fiona\ogrext.py", line 7, in <module>
File "build\bdist.win-amd64\egg\fiona\ogrext.py", line 6, in __bootstrap__
ImportError: DLL load failed: %1 is not a valid Win32 application.

My current research revealed that this can be caused by various reasons such as missing files, missing paths, incompatible compiled dll's etc.

[micahcochran]

@rbuffat I don't think that you are installing Fiona to the OSGeo4w supplied version of python. Here is the command line output from my desktop:

C:\Users\mcochran\Desktop>python -c "import sys; print(sys.executable)"
C:\OSGeo4W\bin\python.exe

C:\Users\mcochran\Desktop>python --version
Python 2.7.4

[rbuffat]

@micahcochran The goal would be to build fiona for different Python versions as in https://github.com/ogrisel/python-appveyor-demo. OSGeo4W only provides one Python version. Does that mean that gdal needs to be built from source to work?

[micahcochran]

@rbuffat I thought the goal was to make it work with OSGeo4w. If the goal is to make sure that it works on multiple versions of python on windows, it seems as if you are going about it the right way. I would hope that you wouldn't have to build GDAL from source to make that setup work.

[snorfalorpagus]

Related: https://github.com/Toblerity/Shapely/issues/367

[rbuffat]

@snorfalorpagus

As you referenced this issue I want to briefly give a short status update on the progress. Gdal + Fiona can be built on appveyor, most of the tests run successfully, expect a few require to build gdal with "ERROR 6: OGR/GPX driver has not been built with read support. Expat library required" and some encoding errors:

test_no_iter (tests.test_collection.GenericWritingTest) ... ERROR 1: Failed to create field name 'label' : cannot convert to WINDOWS-1252
ERROR 1: Failed to create field name 'verité' : cannot convert to WINDOWS-1252

The latest version can be found here: https://github.com/rbuffat/Fiona/blob/wingdal/appveyor.yml

I'm not a Windows C++ guru and have currently not much time available thus there is currently not really progress on it.

[snorfalorpagus]

@rbuffat Rather than building GDAL from scratch I was thinking of using Anaconda and basing the Fiona build on the _conda-forge_ build.

[micahcochran]

The binaries at GISInternals would also be a good shortcut.

[micahcochran]

Using @rbuffat 's work as a starting point. I got GISInternals to binaries to make Fiona compile and install using Python 3.4. There were no Expat errors (presumably because it is included in the GISInternals binary).

The Fiona unit tests show about 20 test are failing or producing errors. I got the same WINDOWS-1252 error.

Would it be okay to skip the tests with a message "FIXME on Windows"? I know that isn't ideal, but it would be a starting point. I think having Appveyor working on some level would be an improvement.

[sgillies]

@micahcochran: I'm in favor, but let's use pytest.mark.xfail() wherever we can.

[snorfalorpagus]

I don't think we should be skipping tests. I think this is actually highlighting a problem with the test.

The test @rbuffat said was failing is this one:
https://github.com/Toblerity/Fiona/blob/8f3d471e510bafc3d653387675d1e7999f5c71e7/tests/test_collection.py#L293-L318

Specifically, this assert:

self.assertRaises(IOError, iter, self.c)

If I run the test manually on Windows I get this:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Miniconda3-x64\envs\python34\lib\site-packages\fiona\collection.py",
line 317, in __next__
    iter(self)
  File "C:\Miniconda3-x64\envs\python34\lib\site-packages\fiona\collection.py",
line 312, in __iter__
    return self.filter()
  File "C:\Miniconda3-x64\envs\python34\lib\site-packages\fiona\collection.py",
line 233, in filter
    raise IOError("collection not open for reading")
OSError: collection not open for reading

So IOError is raised, but somewhere it is converted to an OSError. I wonder where/where? The test probably just needs updating to accept IOError or OSError.

[micahcochran]

@sgillies Good idea using xfail.

I found out that GDAL 2 is on pypi. Mind blown.

@snorfalorpagus You are right. I don't have a lot of time to dedicate to getting Appveyor working on Fiona. There are 500+ passing tests in Windows that currently aren't being run by a CI. The unit tests could use a little bit of work.

I'm looking at marking failing tests in this manner to make it fairly obvious that something needs fixing:

    FIXME_WINDOWS = sys.platform.startswith('win')

    @pytest.mark.xfail(FIXME_WINDOWS, 
                       reason="FIXME on Windows. Please look into why this test is not working.")
    def test_func_failing_on_windows(self):

With a working Appveyor testing, some of the future divergence between Linux and Windows ports should be minimized.

@snorfalorpagus If you want to fix the the problems of the unit tests, give me a couple days and I'll send a link to my branch with commit(s) that pass Appveyor and you can fork it. At the moment, I simply don't have the time or intimate knowledge of Fiona to fix most these unit tests.

[ocefpaf]

I found out that GDAL 2 is on pypi. Mind blown.

But that is still just the source distribution, right? I don't see any wheels that would make it easy to install gdal on Windows.

[micahcochran]

I looked at GDAL 2 on PyPi a little more. It doesn't include GDAL library itself. It looks like it is only the python code and SWIG code in GDAL. It looks like a dump of gdal/swig/python. For Fiona, this is not very useful.

@ocefpaf Yes, source only.

[ocefpaf]

I am one of the maintainers of gdal on conda-forge and I would love if you guys consider using it here. That would help us to improve/debug/update our recipe much quicker. (Our gdal binary was built mostly with fiona and rasterio in mind.)

[snorfalorpagus]

Apparently IOError has been merged into OSError in 3.3: https://docs.python.org/3.4/library/exceptions.html#OSError

[micahcochran]

@sgillies I couldn't get @pytest.mark.xfail to work with nose, the tests would just fail. Also, @unittest.expectedFailure marks that test as an "ok" result, which completely covers up that there are are any problems. Very bad.

I'm just going to mention that other projects are chosing to move to another testing framework due to nose not really being maintained anymore. The choices are pytest, nose2, or even just unitest itself.

Therefore, the changes I propose skips 34 tests under Windows. Many of which are PermissionErrors that I assume Windows doesn't like file handles being opened multiple times.

There seem to be a few ERRORs (GDAL Errors?) that don't bubble up to the level of being Exceptions. The tests pass. :see_no_evil:

There are two different tasks that result in getting Appveyor working. (1) Installing GDAL with various versions of Python and GDAL. (2) Getting the unittests so that they don't fail on Windows.

For (1) I chose GISInternals because it is the official(?) Windows binary. GDAL uses it for all the dependent libraries on its Appveyor. It was pretty simple once I figured out the structure. I chose not to use conda because I'm not familiar with it, but I think it is a good option.

If my PR gets committed, anyone can work on improving task (1) or (2) without having to work on both tasks at the same time.

[micahcochran]

If expected failures are a must-have, perhaps the unit testing should move from nose to either nose2 or py.test. The nose readthedocs recommend that new projects use another framework.

[micahcochran]

With PR #353 merged there is now a working Appveyor CI.

Please feel free to use it as a starting point to install gdal binaries via conda-forge, make multiple build configurations, and figure out what is wrong with those 41 skipped unit tests on windows.