Update to support running on Windows

[chhackett]

Added support for running on Windows, in command line or Powershell terminals.

Currently terminal emulators such as mintty, ConEmu, alacritty, etc are not supported.

Addresses issues #1607 and #53.

[xsebek]

Thanks @chhackett, I look forward to playing Swarm on Windows. 🚀

Could you please also update the CI file and add Windows to the test matrix?

[xsebek]

Why not use only vty-crossplatform? 😕

[chhackett]

The only reason for the explicit dependency on unix/windows libraries is because the ColorMode setting is not part of the default configuration anymore, but down in the unix/windows settings.

That is an unfortunate consequence of the design choice we made in how to split up the unix/windows implementations.

[chhackett]

So now that I'm thinking about this, I wonder if we made a mistake by putting ColorMode in the UnixSettings/WindowsSettings data types. It is something that we could potentially add to the VtyUserConfig
since both implementations support it.
That would make one less reason for users to need to have an explicit dependency on the unix/windows plugins.
@jtdaugherty - what do you think?

[jtdaugherty]

Looking back at the change history, this was an oversight. I moved the color mode detection code to vty-unix, but there was a lot going on with the split-up of Config that the color mode setting got moved in the shuffle. Since the ColorMode type lives in vty, it makes sense to me to put that in the Vty user config as well, even if the backend packages still do their own detection. I think the caveat would be that backends might need to ignore or override the setting if it's unsuitable, but that was already true before Vty 6.

[jtdaugherty]

I'll look into the implementation and see what this would involve.

[chhackett]

Thanks @chhackett, I look forward to playing Swarm on Windows. 🚀

Could you please also update the CI file and add Windows to the test matrix?

I'd be happy to do that, but I'm not sure what change I should make to the CI file (assuming you mean cabal.haskell-ci).

And I don't know where to find the test matrix. Sorry, I'm new to contributing to github projects.

[chhackett]

@xsebek
OK, I've been reading about the haskell github CI project, and I'm guessing you were hoping I would add a Windows section to the /.github/workflows/haskell-ci.yml file?

Unfortunately, as far as I can tell, there is no Windows version. Am I missing something?

[p3rsik]

@chhackett I believe you would want to define new job for windows(as done here) with it's own steps and compiler matrix for windows.

This line here specifies the runner OS. Unfortunately you can't reuse much of the setup code in the linux runner, since it's linux specific, but you can use it as a reference on what needs to be done on windows runner.

That said, it's a hard task, if you aren't familiar with github workflows and windows, albeit an interesting one and will definitely add something to your toolbox.

[chhackett]

@p3rsik @xsebek
I would love to learn how to define a workflow job for windows. However, my time available for doing this kind of work is very limited. And right now I have my hands full working out some bugs in the vty-windows implementation. So I'm unlikely to get to this task for a while. So if anyone else has bandwidth and wants to take that on, please be my guest.

And just to be clear, I'm not promising I'll ever get around to doing this. I contributed this PR in the spirit of being helpful. But I want to stay focused on improving the experience of using vty/brick on Windows, at least for now.

[byorgey]

@chhackett No worries! We really appreciate the contribution, and your work on vty + brick. One of the rest of us can definitely take on the task of setting up the CI for Windows.

[byorgey]

Incidentally, the .github/workflows/haskell-ci.yml file should not be edited directly, it is auto-generated by https://github.com/haskell-CI/haskell-ci . Now that I look at it, though, I am not sure whether haskell-ci has support for testing on Windows.

[xsebek]

I forgot it was so linux specific, we can look into it separately - let's just add an Issue for Windows CI.

[byorgey]

So it sounds like there may be changes coming which would allow us to depend only on vty-crossplatform instead of having a conditional dependency on one of vty-unix and vty-windows. Should we wait for that, or should we go ahead and merge now and make those updates later? @jtdaugherty , any thoughts on a potential timeline on your end?

[jtdaugherty]

@byorgey I plan on looking into it more tonight. I started working on a patch earlier today, but it turns out that it's awkward to have a setting in vty's VtyUserConfig that vty itself doesn't do anything with -- the platform packages will need to make use of it -- so I'm not yet clear on what a good design will turn out to be. If it isn't too much trouble, I'd say go ahead and move forward with what you have and then adjust later. I wouldn't want to hold up your work unless you find the patch unpalatable and would like to hold off in the hope of something better.

[byorgey]

@jtdaugherty OK, thanks, no rush. We'll go ahead and merge this, but I'll add an issue to remind us to possibly update in the future. Conceptually, I'd love to eventually be able to depend only on vty-crossplatform and thus have a sort of static guarantee that we are limited to doing things that are supported on both platforms. But I don't have a problem with the conditional platform-specific dependencies for now.

[jtdaugherty]

Understood, and I definitely don't see depending on specific platform packages as a good thing, either, if you're going for cross-platform support. So I will aim for something that removes that requirement.