cmake workflows on Windows fail due to Python 3.7 dependency

[pmeier]

CPU: https://app.circleci.com/pipelines/github/pytorch/vision/22939/workflows/787176d2-d6fb-4482-876e-35a6078d00f8/jobs/1819932
GPU: https://app.circleci.com/pipelines/github/pytorch/vision/22939/workflows/787176d2-d6fb-4482-876e-35a6078d00f8/jobs/1819929

This was likely forgotten in #7110.

cc @seemethere @atalman @malfet

[pmeier]

It seems we aren't using a custom conda env at all here, but basically rely on whatever is installed on the images:

vision/.circleci/config.yml.in

Lines 9 to 20 in 85983a5

	executors:
	windows-cpu:
	machine:
	resource_class: windows.xlarge
	image: windows-server-2019-vs2019:stable
	shell: bash.exe
	windows-gpu:
	machine:
	resource_class: windows.gpu.nvidia.medium
	image: windows-server-2019-nvidia:stable
	shell: bash.exe

Since we already have something extra for Windows

vision/packaging/build_cmake.sh

Lines 23 to 26 in 85983a5

	if [[ "$OSTYPE" == "msys" ]]; then
	conda install -yq conda-build cmake future
	pip install dataclasses
	fi

I've tried to explicitly install Python 3.8 there in #7182. However that leads to other issues.

[malfet]

Hmm, imo we should fix the workflow or disable it, but keeping it broken does not make sense to me.

[pmeier]

TBH, I'm not really sure what the cmake workflows even do. And I don't think we even some documentation of that. It should be related to a C++ only build, since we run

vision/packaging/build_cmake.sh

Lines 109 to 111 in 9b233d4

	popd
	cd examples/cpp/hello_world
	mkdir build

but in the light of #7106, I'm not sure that is even doing something useful.