Prefect: Determine and publicize our stance on Windows support

[cicdw]

We currently don't have an "official" stance on Windows support.

I think _guaranteeing_ full support for windows (including dev environments such as documentation building and the ability to deploy to Cloud) might not be feasible, but being able to cleanly articulate what can be expected to work vs. not work might be possible.

I believe that _most_ of our local execution should work on Windows, with minor adjustments to how we handle temporary files (see for example #858 ).

There are varying degrees to which we can push this:

• [ ] "we don't support Windows at all and recommend doing development within a Docker container"
• [x] "we don't officially support Windows, but will respond to issues as they are opened, bandwidth permitting"
• [ ] "we support Windows insofar as we have a CI job that is required to pass for PR merges; this doesn't guarantee deployment will work correctly"
• [ ] "we fully support Windows, including for Cloud deployments"

This last item is probably impossible, given that the Flow needs to be serialized to binary and placed inside a Docker container for most versions of Cloud deployment, and I'm not sure how much we can ensure this process is cross-platform compatible.

I'm personally leaning towards having an appveyor CI job, although in truth I think it will be a large pain to debug given that I don't personally have access to a Windows machine (I'm open to hearing of ways to handle this).

cc: @jlowin @joshmeek @dylanbhughes @zdhughes for any opinions / discussion points I might be missing

[jlowin]

I worry that a CI job that, sort of by definition, would only fail for odd cross-OS reasons that we (Prefect) and the majority of our users would neither expect nor have an easy way to solve — can’t be part of the pipeline at this stage. Without dedicated support, it would introduce friction far disproportionate to the comfort it gave any Windows users. I would vote for option 2 at this time, myself.

[dhirschfeld]

I'm on Windows and keen to give prefect a go to replace a custom dask ETL pipeline. I'm happy to open issues/PRs for any problems I come across...

[joshmeek]

@dhirschfeld Absolutely! That would be awesome!

[jlowin]

@dhirschfeld 👍 that would be wonderful to hear how it goes

[cicdw]

Update on this; I tried to see what I could learn (as a non-Windows user) on a Windows machine. I used GitBash + a full install of Anaconda3.

• installing Prefect was a pain; I had lots of weird version conflicts that I had to manually resolve (the two that caused the most trouble were pyyaml and pytest)
• 31 tests failed: as far as I could tell, these errors fell into two categories:
  
  
  
  • Errors related to tempfile usage _within_ tests ("Permission denied"); these are easily fixable with a temporary file opening utility which closes the file prior to use and manually deletes it after
  
  
  • Errors related to serialization; these arose from the timeout handler and the is_serializable debugging utility function. The timeout handling errors are coming from the fact that lambda functions aren't serializable, and to be totally honest I'm not sure why they don't occur on Unix based machines as well.
  
  

Overall, I have two takeaways:
1.) working on Windows machines is really difficult and unpleasant for me
2.) the actual errors (after dealing with installation), were very mild and appear to be easily fixable

I didn't reach a conclusion with this exercise, but it was definitely informative.

[jlowin]

That's very helpful. It sounds like we can make the experience at least not-terrible with a small amount of work, but larger guarantees may require deep dives?

[cicdw]

Yup, that's my impression.

[cicdw]

Ok, I've spent time on this and I've concluded that all of the core functionality of Prefect _should_ work on Windows (as we suspected).

However, given my complete lack of skill at navigating Windows machines and how hard it is for me to even setup a proper dev environment, I'm going to close this issue in favor of "we will respond to issues as they are opened" until this resurfaces as a priority.