Hacker News new | past | comments | ask | show | jobs | submit login

I'm still in the process of building it. (Need to get my C deps straightened out for the python integration.) The main problem here is that several of these packages (`lime` included) are not "go gettable."

---

Completion:

If you `go get github.com/quarnster/completion` it will error out but `$GOPATH/src/github.com/quarnster/completion` should contain the downloaded source files.

If you go into `$GOPATH/src/github.com/quarnster/completion/build` there's a Makefile you can run (with `make`) that should install the package.

----

Parser:

The `github.com/quarnster/parser` package is also not properly go gettable.

You need to cd into `$GOPATH/src/github.com/quarnster/parser/pegparser` and run `go install` which will put it in `$GOPATH/bin` (I didn't try, but `go get github.com/quarnster/parser/pegparser` might actually work.)

This package is just poorly factored in my opinion. The root package contains the library code, and the binary is in a sub-package. It really should be the other way around: the root package should build the binary, which would import the library from a sub-package. That or they really should be two completely separate packages in distinct namespaces.

---

QT5:

The `github.com/salviati/go-qt5` library is _also_ not go gettable. However `go get` will download the source to your `$GOPATH` which should be enough for the Makefile to find it.

---

This is a rather frustrating build because so many of these packages don't follow the proper conventions for Go's package management.




I gave up! It fails to build miserably. What's the point of open-sourcing something when you're not open to the community. I mean, do this when it's ready for prime time, provide binaries, and they open-source it so that people can have some confidence in what they're running on their machines.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: