Test build of 34c0dd5

[sgillies]

That's the no _loading rasterio PR https://github.com/rasterio/rasterio/pull/2594.

[snowman2]

Added a fix related to https://github.com/pyproj4/pyproj/pull/1132

[sgillies]

@snowman2 not all heroes wear capes :superhero:

[snowman2]

Glad to see the fix worked 🎉

[snowman2]

I n case it is helpful, this is how pyproj pulls in the latest vcpkg: https://github.com/pyproj4/pyproj/blob/bc7805ccc813b40ab28099ef305821300f149aad/.github/workflows/release.yaml#L101-L103

          cd "$VCPKG_INSTALLATION_ROOT"
          git pull > nul
          ./bootstrap-vcpkg.bat -disableMetrics

[snowman2]

I just added: --x-install-root=$VCPKG_INSTALLATION_ROOT/installed

From: https://github.com/pyproj4/pyproj/blob/5723f370287bc71b9d6de80b8acf3ea517931ed2/.github/workflows/release.yaml#L104

[snowman2]

looks like you already added it and removed it

[sgillies]

@snowman2 yeah, I was using that (following your example) in 1231248, but vcpkg seemed to disregard it and and installed packages to locations like c:/vcpkg/packages/gdal_x64-windows (see https://github.com/rasterio/rasterio-wheels/actions/runs/3192686214/jobs/5210441743#step:5:1014), which is not helpful at all. vcpkg is slowing driving me insane.

[snowman2]

It would be really nice if there was a temporary machine to log into and explore after the vcpkg install completed. Would really make this process a lot less painful.

[rbuffat]

Not sure if it works well on windows, but with this action it is possible to connect to a workflow session: https://github.com/mxschmitt/action-tmate

[snowman2]

Not sure if it works well on windows, but with this action it is possible to connect to a workflow session: https://github.com/mxschmitt/action-tmate

That looks really useful.

[sgillies]

@snowman2 there it is. vcpkg switched on me, it's installing stuff to installed/x86-windows now instead of installed/x64-windows: https://github.com/rasterio/rasterio-wheels/actions/runs/3205013336/jobs/5236997241#step:9:9. What a terrible system. I suspect explicitly specifying the triplet will solve this.

[snowman2]

Good eye :+1:

I suspect explicitly specifying the triplet will solve this.

https://github.com/pyproj4/pyproj/blob/3009c5c9ab8cbffc30a39831bc9624906f9e388e/.github/workflows/release.yaml#L97-L98

        env:
          VCPKG_DEFAULT_TRIPLET: ${{ matrix.triplet }}

[snowman2]

Progress! Only 1 failure:

data = local('C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pytest-of-runneradmin\\pytest-0\\test_copyfiles_same_dataset_an0')

    def test_copyfiles_same_dataset_another_name(data):
        """A dataset can't be copied to itself by another name."""
        path = str(data.join('RGB.byte.tif'))
        with pytest.raises(RasterioIOError):
>           rasterio.shutil.copyfiles(path, 'file://' + path)
E           Failed: DID NOT RAISE <class 'rasterio.errors.RasterioIOError'>

[sgillies]

Thanks for the assist @snowman2 ! I guess something changed in 3.5.2? We're not current in rasterio's tests: https://github.com/rasterio/rasterio/actions/runs/3206825922.

[snowman2]

Thanks for working on this @sgillies :+1: - this one was definitely interesting to figure out.

[snowman2]

We're not current in rasterio's test

https://github.com/rasterio/rasterio/pull/2606

[sgillies]

@snowman2 @vincentsarago https://github.com/rasterio/rasterio-wheels/actions/runs/3206563664 has two failures on Windows despite all the tests passing with the ubuntu-small-3.5.2 image. I'm inclined to skip these for the 1.3.3 release and go ahead with a little bit of undefined behavior, hopefully resolving the issues before 1.3.4.