search

MatrixAI / Emergence

Distributed Infrastructure Orchestration
Apache License 2.0
1 stars 0 forks source link

Go + Haskell Workspace #31

Closed mokuki082 closed 5 years ago

mokuki082 commented 5 years ago

Just something that I've noticed while working with Go and Haskell, probably trivial but i figured it would be a good idea to put them down anyway. @CMCDragonkai

I've been nesting my Go workspace under the main Haskell library for hs-libcontainer. A problem i found with that approach is that sometimes I would be using other Go libraries for development purposes (debugger, etc.), and that gets messy very quickly as all of those libraries are included in the project.

Conversely, if I have the stack project under Go, in this structure:

/go-workspace
    /bin
    /pkg
    /src
        /github.com/Matrix-AI/hs-libcontainer/
            -- Stack related files
            -- Version control at this level
            /package.yaml
            /app
            /src
                /go-libcontainer

Then version control won't pick up the external libraries that is not included in the project. However, for the external libraries that should be included in the project, we could consider using Runc's approach, which is to put all the other dependencies under a vendor folder at the project root, which can be picked up by go build.

The second approach requires a symlink at Matrix-AI for go-libcontainer if go build is used though, which can get messy.

Both approaches separates the build process into two stages: first Go and then Haskell. That can actually be quite useful at the current stage because I sometimes just want to see if the Go code compiles or not.

CMCDragonkai commented 5 years ago

I have now completed the Haskell-Demo https://github.com/MatrixAI/Haskell-Demo and Golang-demo https://github.com/MatrixAI/Golang-Demo.

The new Golang way doesn't require using the GOPATH structure as was done before, it should simplify the directory structure. Golang dependencies themselves still doesn't use Nix, as they are not packaged in Nixpkgs, but they are brought in via the go.mod, but that itself can be automatically converted or manually converted to the deps.nix.

The main issue would be any Golang dependencies that are not Go module based, but still uses the old GOPATH style. Unless we have to fork and modify it, we can keep them as upstream Go dependencies and use our own Go module that wraps/exposes them.