Windows support

[mjcarter95]

As it stands, only Linux and MacOS are supported. Are there any plans for extending support to Windows? If so, I'd be happy to help push that forward.

[ahartikainen]

I'm not against it, but also not too hopeful.

First, the mingw toolchain solution used in pystan2 is not a good solution. If we want to support Windows, we should use native windows tools.

Then, if we go with msvc (assuming clang+libc support doesn't come to python) we need to figure out how do we handle all the precompilation and other things.

Then, we currently use socket with non-windows functionality. We would probably need to move to use ipv6 (or whatever is that name). Not sure how fast it is.

If we support Windows, it shouldn't be 2-5x slower than linux to do sampling.

[mjcarter95]

Sorry for the slow response.

Out of interest, why is the mingw toolchain solution not a good solution?

I should have some time over the weekend/next week to have a play with msvc and see if I can get things to compile.

[ahartikainen]

I can try to give you some pointers here, but these might be incorrect. I'm not the best authority on this subject.

mingw-w64 + libpython packages that work with Python are currently found in conda package manager. They are unofficial and "hacked" together. (they are great, but I still think they are hack). There are many users (e.g. in company settings) who can not use.

Also I think Stan programs compiled with mingw are slower than the programs compiled with msvc, but I might be wrong about this too.

After 3.6+ Python has changed its policy against compiled extensions (CPython is compiled with msvc) so to create official / native python extensions we would need to use msvc.

https://wiki.python.org/moin/WindowsCompilers

[riddell-stan]

I think it's safe to say that we would have to add or change some code in httpstan to get things working with either MSVC or mingw. Past experience has given us (and many other developers) evidence that supporting things in Windows is more challenging than supporting things on Linux and macOS.

Since Stan now has a semi-formal way of discussing these kinds of big changes, I suggest we use it. A design document describing how to support Windows could list the problems encountered in the past and sketch solutions for each. It should also describe how long-term support would be guaranteed. For example, I'm not able to actively work on Windows maintenance since I don't know anything about Windows.

Let's at least table this until 3.0 is out?

@mjcarter95 if you have free cycles, I'd really welcome help with #150. It's a bit of a challenge and the benefits are pretty big. I'm going to focus on getting #129 done before the release candidate freeze on Feb 25 (see https://discourse.mc-stan.org/t/pystan-3-release-schedule/20819).

[mjcarter95]

@ahartikainen Interesting, thank you. I wasn't aware of the policy change after Python 3.6

@riddell-stan Formalising a design document sounds like a good approach. Happy to look at #150 over the weekend.

[mjcarter95]

@riddell-stan A quick update to say that I hope to finalise #150 this weekend.

[riddell-stan]

I'm closing this since we added a FAQ entry, https://pystan.readthedocs.io/en/latest/faq.html#is-windows-supported