Coverage remained the same at 78.4% when pulling dcb22a2 on jorisvandenbossche:test-windows-py38 into 0af2ed3 on Toblerity:shapely-2.0.

See pygeos/pygeos#383

The best solution is to copy the DLLs, as the PATH fix doesn't work as found in pygeos/pygeos#382

Hmm, OK, I hoped that setting the path here would work, as copying the geos dlls into the pygeos directory is not that straightforward here, since we pip install pygeos (so I would need to find a robust way to get the path to the pygeos install location).

I also don't want to spend too much time on it, because after #1211, the next step would be to move the pygeos' repo content in here, and then one of the first steps would be to consolidate the CI scripts (and pygeos' scripts are already handling this fine). So temporarily disabling the windows tests for python >=3.8 (as I now did in #1211) is maybe also good enough

Maybe temporarily use os.add_dll_directory(path)? It would need to be embedded in the Python code.

I would do that in the testing code? (eg in conftest.py)

In theory it would need to be os.add_dll_directory(path) before the first import pygeos.

As the error stems from shapely\geos.py:4, it would need to be moved just before there. Otherwise the modification looks like it should work.

@mwtoews thanks for the help! This seems to be working, as there is now an actual failure:

    @requires_geos_380
    def test_point_empty():
        g = wkt.loads("POINT EMPTY")
>       assert g.wkb_hex == hostorder(
            "BIdd", "0101000000000000000000F87F000000000000F87F")
E       AssertionError: assert '010100000000...000000000F8FF' == '010100000000...000000000F87F'
E         - 0101000000000000000000F87F000000000000F87F
E         ?                         ^               -
E         + 0101000000000000000000F8FF000000000000F8FF
E         ?                         ^                +
tests\test_wkb.py:162: AssertionError

Empty strikes again! Looks familiar. PostGIS decodes both to POINT EMPTY:

postgis=# WITH data as (SELECT
postgis(#   '0101000000000000000000F87F000000000000F87F' A,
postgis(#   '0101000000000000000000F8FF000000000000F8FF' B)
postgis-# SELECT 'A'::text test, A, ST_AsText(A) FROM data
postgis-# UNION SELECT 'B',      B, ST_AsText(B) FROM data;
 test |                     a                      |  st_astext
------+--------------------------------------------+-------------
 A    | 0101000000000000000000F87F000000000000F87F | POINT EMPTY
 B    | 0101000000000000000000F8FF000000000000F8FF | POINT EMPTY
(2 rows)

Yes, both are valid representations (different kind of NaN values), but so when converting to WKB, which of the two you get depends on your architecture. What I added here makes that test more robust by asserting the bytes represent NaN, instead of hardcoding exactly the expected bytes (this is what we do in pygeos).

This now includes the change I originally did in #1123

Last suggestion is to clean-up the "Checking geos_c.dll" section in appveyor.yml around line 55, as this was primarily for ctypes

Green! :)