Please support Windows.

[mrolle45]

My tale of woe
I have a Windows PC, and I wanted to run pytype on my code. I had to install WSL and then load several needed packages. Not only was this a big pain, but when pytype gave me some bad results, I tried debugging it.
I'm not familiar with the latest IDEs on linux, nor did I want to spend the effort of learning to debug Python code visually (and load even more packages).
So I resorted to inserting lots of print() calls in the code until I figured out what the problem was.
About two days spent on this effort.
I managed to get good pyi outputs for most, but not all, of my source code. I then tried running merge_pyi on the good ones, only to find out that merge_pyi crashed.
On the hunch that at least merge_pyi didn't do anything weird, I installed pytype on my Windows Python, and used Visual Studio to debug it. It worked without problems. I was able to find and fix the bug, and file an issue about it. See #1153.

The pitch
I presume that there can't be too much involved in getting the entire pytype package to run correctly on Windows. After all, Python is mostly portable.
It would be a great assistance to Windows Python users if they could run pytype directly.
Thank you.

[martindemello]

we would definitely love to have better support for windows, the problem is that there are only three pytype devs, and we all use linux. we are very open to pull requests for windows and macos support, but we are unable to do the work ourselves.

[IIHERO4]

we would definitely love to have better support for windows, the problem is that there are only three pytype devs, and we all use linux. we are very open to pull requests for windows and macos support, but we are unable to do the work ourselves.

Hey, i was just wondering what would be necessary in order to support windows.

[martindemello]

@IIHERO4 just an iterative process of running pytype, finding issues, investigating and fixing them - i'm afraid we don't have a proper roadmap because we don't even know what all the issues are.

the current blocker is #90 - it's possible that everything will just work after that is fixed, but it's also possible that other issues are hiding behind it.

[HexDecimal]

The designated initializers like the ones here seem to be non-standard and break MSVC.

pytype/pytype/typegraph/cfg.cc

Lines 501 to 547 in efc1fd9

	PyTypeObject PyProgram = {
	PyVarObject_HEAD_INIT(&PyType_Type, 0) tp_name : "Program",
	tp_basicsize : sizeof(PyProgramObj),
	tp_itemsize : 0,
	tp_dealloc : ProgramDealloc,
	#if PY_VERSION_HEX >= 0x03080000 // 3.8
	tp_vectorcall_offset: -1,
	# else
	tp_print : nullptr,
	# endif
	tp_getattr : nullptr,
	tp_setattr : nullptr,
	#if PY_VERSION_HEX >= 0x03050000 // 3.5
	tp_as_async : nullptr,
	#else
	tp_compare : nullptr,
	#endif
	tp_repr : nullptr,
	tp_as_number : nullptr,
	tp_as_sequence : nullptr,
	tp_as_mapping : nullptr,
	tp_hash : nullptr,
	tp_call : nullptr,
	tp_str : nullptr,
	tp_getattro : ProgramGetAttro,
	tp_setattro : ProgramSetAttro,
	tp_as_buffer : nullptr,
	tp_flags : 0,
	tp_doc : program_doc,
	tp_traverse : nullptr,
	tp_clear : nullptr,
	tp_richcompare : nullptr,
	tp_weaklistoffset : 0,
	tp_iter : nullptr,
	tp_iternext : nullptr,
	tp_methods : program_methods,
	tp_members : nullptr,
	tp_getset : nullptr,
	tp_base : nullptr,
	tp_dict : nullptr,
	tp_descr_get : nullptr,
	tp_descr_set : nullptr,
	tp_dictoffset : 0,
	tp_init : nullptr,
	tp_alloc : nullptr,
	tp_new : ProgramNew,
	};

Even if you used C++20 designated initializers PyVarObject_HEAD_INIT would cause non-designated initializers to be mixed in and break MSVC. I solved this issue by switching from Python static types to heap types rather than leaving a lot of attributes without names.

The CMake script doesn't set a C++ standard so MSVC defaults to one that's too early. I added set(CMAKE_CXX_STANDARD 17) to the top script but there might be better options. On Windows I was able to run both pip install -e . and python build_scripts/build.py after this change and the one above.

The issues with #90 still exist. pytype generates absolute paths with Windows drive names C:\ in them and Ninja thinks the colon is part of the build command instead of part of a path. The Ninja build file will run if you change some of the paths to be relative. I think only the paths on the build/check lines are having issues. I don't know how you're normally supposed to escape the drive path.

[Avasam]

#727 (comment)
Hi, I'm trying to look into this MSVC syntax error, but for the life of me I can't figure out how to use /std:c++20 instead of /std:c++14 when doing pip install . -e so I can try some things. (namely using standard designated initializers)

[rchen152]

Looks like we have std=c++11 specified here:

pytype/cmake/modules/PyTypeUtils.cmake

Line 18 in 8ee2d9c

add_compile_options("-std=c++11")

and cxx_std=11 here:

pytype/setup.py

Line 47 in 8ee2d9c

cxx_std=11,

Try changing one or both of those?

[hhoppe]

I've been using pytype in WSL (Windows Subsystem for Linux) for a while.
I just tried Windows-native Python and was amazed that just about everything I have ever used works, e.g.:
pip install -U jupyter jupyterlab jupyterlab-execute-time jupytext autopep8 flake8 mypy pyink pylint pytest pdoc matplotlib numba numpy scipy scikit-image tqdm Pillow plotly keras tensorboard tensorflow-estimator torch 'jax[cpu]' opencv-python-headless graphviz kaleido networkx more-itertools sympy nbformat requests requests_oauthlib configparser z3-solver ipywidgets 'pyvista[jupyter]' mediapy resampler

The only packages that failed were: tensorflow and pytype.
Just saying... :-)