Graphql-engine: (Hasura Server) Windows compile / Windows Docker container

[erichiller]

This is a feature / enhancement request. But if it's currently not possible, but is with relatively easy changes, I would be interested in trying to solve myself.

Summary

Unless I've missed something there are no Windows builds or Windows-based containers but I don't see any reason that it isn't possible. I've tried building myself, and the only apparent error I found was that hs-jose depended on the unix package. However, upon further inspection it seems it only needed that for the unused _examples_. So I forked hs-jose , removed the _examples_ section from hs-jose's cabal config, then included my repo into hasura/graphql-engine/server/stack.yaml. Re-ran stack build --fast and while I now get past the planning stage, I still encounter errors when building.

Has there been any thoughts on Windows builds ? Do you see any glaring issues in my procedure? Any advice is appreciated!

[0x777]

Hi! None of us at Hasura use Windows for development. In fact we just realised that the current master doesn't build even on macOS because of a dependency on select package (@lexi-lambda is checking if it is a quick fix). Maybe post that you can give it a shot again. Can you post the build log?

[erichiller]

Thanks for the quick reply!
I ran build once and got through a large percentage of the build. I assume it caches its progress, here is the second time I ran it, if you need me to purge and re-build, let me know. (or if you need any other information at all).

The build output is long ( I ran it with --verbose) so I put it in a gist

[lexi-lambda]

The particular failure that your build is bumping into does appear to be the select issue that @0x777 mentioned, which should be fixed by hasura/pg-client-hs#13. That isn’t to say you won’t run into some other, later problem after that one is resolved, but at least it would be forward progress.

[marionschleifer]

@erichiller Could you try building master again and let us know if it works? 🙂

[erichiller]

@marionschleifer Sorry for the delay, I ran

git pull
stack clean
stack purge
stack update

But I get stuck at the same step data-dword

It ran overnight and this morning, at least 12 hours at 50-100% CPU and sat at this step for the majority of the time (so I don't think it just needed more time).

Here are the last few lines of output

x509                     > copy/register
x509                     > Installing library in C:\Users\Eric\AppData\Roaming\stack\snapshots\07ea1279\lib\x86_64-windows-ghc-8.6.3\x509-1.7.5-LQtJ40lJj1gBNNpgGSHsA6
x509                     > Registering library for x509-1.7.5..
jose                     > configure
jose                     > Configuring jose-0.8.0.0...
jose                     > build
jose                     > Preprocessing library for jose-0.8.0.0..
jose                     > Building library for jose-0.8.0.0..
jose                     > [ 1 of 18] Compiling Crypto.JOSE.AESKW
jose                     > [ 2 of 18] Compiling Crypto.JOSE.Error
jose                     > [ 3 of 18] Compiling Crypto.JOSE.Compact
jose                     > [ 4 of 18] Compiling Crypto.JOSE.TH
jose                     > [ 5 of 18] Compiling Crypto.JOSE.JWA.JWS
Progress 26/54: data-dword

I put the full output, including commands ran, in this gist

Ideas? Possibly I am doing something wrong.

[lexi-lambda]

@erichiller Sorry for the long delay in responding. Unfortunately, I have zero experience building Haskell code on Windows, and I do not have access to a Windows machine to investigate the issue myself. That said, I would not be shocked if Hasura or any of its dependencies assume a POSIX environment, since I don’t think any explicit effort has been made to make it cross-platform.

The intended (and, currently, only supported) way to run Hasura is via one of the distributed Docker containers (i.e. the images published to hasura/graphql-engine on Docker Hub). Could you elaborate on why you’d like to run Hasura in a Windows environment? Is it a convenience/nice-to-have kind of thing, or is there some particular use case you have in mind that would require it? If it’s the latter, we can consider adding support, but my guess is that we’re unlikely to take on the significant burden of supporting and testing on multiple platforms unless there’s a very compelling reason to do so.

[erichiller]

Not a problem, thanks for the reply.

The reason I was looking to run on Windows (Windows Container) is because the Windows Server version I have only supports Windows containers, Linux containers don't run. If it is something you could add support for that would be great!

[akhedrane]

hi, first i would thank you for this great tool.
we are in very opinionated env and we have to work with windows binary build to run with Nomad instead of docker.
so i added jose-0.8.1.0 as extra dep in stack config and removed unix dep from cabal file.

we got this error:

--  While building package pg-client-0.1.0 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.5.exe --builddir=.stack-work\dist\e626a42b build lib:pg-client --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\sr\graphql-engine\server\.stack-work\logs\pg-client-0.1.0.log

    Configuring pg-client-0.1.0...
    Preprocessing library for pg-client-0.1.0..
    Building library for pg-client-0.1.0..
    [1 of 7] Compiling Database.PG.Query.Connection ( src\Database\PG\Query\Connection.hs, .stack-work\dist\e626a42b\build\Database\PG\Query\Connection.o )
    <command line>: can't load .so/.DLL for: D:/laragon/bin/POSTGR~1/POSTGR~1.0-1/lib\libpq.dll (addDLL: D:\laragon\bin\POSTGR~1\POSTGR~1.0-1\lib\libpq or dependencies not load)

[tjad]

With some effort in understanding the project and its tool chain, it is possible to produce a native windows build.

@erichiller Jose shouldn't be a problem anymore - there's been a recent update to the dependent regarding that issue.

Only issue I've run into so far is with the hasura hs postgres driver, minimal change could fix. Only incompatibility of threadWaitRead that I've seen between *nix / windows. Will post updates if any further issues encountered with more extensive use.

[akhedrane]

@tjad could you share your fixes in a forked repo?