Live data from Hacker News

Problems with Go Get

0x74696d.com

11–20 of 86 posts

Re: Problems with Go Get

#11
post #7

Makefiles, build: docker build Ugh, more Linux-Only. Don't follow this please. (This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.) What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go b…

What? GNU make works everywhere. I've used it on Window, OS X, every Linux distro I've touched and all the BSDs

Re: Problems with Go Get

#12
post #9

I haven't written much go, so I'm just riffing here, but could you do something similar to what the author is suggesting with git submodules?

Yes, you absolutely could. You wouldn't even need to fork the dependencies.

Re: Problems with Go Get

#13
Lately I've been working on something to address the problems that I see with go get.

https://github.com/skelterjohn/wgo

It's a workspace layer on top of the go tool, with added support for repository pinning. You 'wgo get' the repo you want, and 'wgo {save,restore}' will pin/fetch it in the future. Also, 'wgo FOO' will do 'go FOO' with GOPATH set for your workspace, so all the normal goodness is still there.

It also makes it so you don't have to manage the GOPATH env var anymore, which I always found to be a pain.

Re: Problems with Go Get

#14
post #7

Makefiles, build: docker build Ugh, more Linux-Only. Don't follow this please. (This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.) What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go b…

Take a look at https://github.com/skelterjohn/wgo - it's vendoring in a way that 'go build' (and 'go get') still work :)

Re: Problems with Go Get

#15
post #9

I haven't written much go, so I'm just riffing here, but could you do something similar to what the author is suggesting with git submodules?

git submodules are sort of a pain to manage. I think they've more or less failed as a git feature.

Re: Problems with Go Get

#16
post #11
post #7

Makefiles, build: docker build Ugh, more Linux-Only. Don't follow this please. (This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.) What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go b…

What? GNU make works everywhere. I've used it on Window, OS X, every Linux distro I've touched and all the BSDs

Yes, I know about GNU make. The point is not GNU make, the point is needing to find out how to install third-party program on my OS of choice to build an app that should be as easy as "go build" because of the Programming Language used.

Maybe once that new fancy OneGet is on Windows (and maybe even becomes as good as brew looks on OSX, which I've never used) it will no longer bother me.

Re: Problems with Go Get

#17
It's a meta point but the semantic of `go get` is so beautiful I'm profoundly disappointed that the tool isn't usable.

Being able to dispatch a co-routine with `go ...` is beautiful. Being able to fetch a dependency with `go get` is just as succinct and expressive.

I'm not up on Go language development but imho the world would be a better place if they could fix the behaviour to preserve the syntax!

Re: Problems with Go Get

#18
I really like the OP's structure and makefile, but it looks like a pain to work against Golang's grain here, even though the methodology makes a lot more sense to me.

Maybe I have misunderstood the documentation, but what I truly, truly don't get about Go's $GOPATH is that it wants (1) my project directory to have some kind of canonical path, and (2) to pollute my project directory with dependencies. I have done a bunch of Go development and I still don't get it.

So for example, I have myproject, which I naturally want to organize in this way:

    $HOME
      Projects
        foo
          .git
          src
            main.go
            stuff.go
          assets
            photo.png
            something.xml
          scripts
            setup_database.sh
          config
            config.sample.json
          Dockerfile
          Makefile
Go wants me to throw this away and structure it like this:

    $HOME
      go
        bin
          [...]
        src
          github.com
            BurntSushi
              toml
                [...]
            zenazn
              goji
                [...]
            myaccount
              myproject
                .git
                main.go
                stuff.go
                assets
                  photo.png
                  something.xml
                scripts
                  setup_database.sh
                config
                  config.sample.json
                Dockerfile
                Makefile
I'm supposed to work within this jungle of dependencies and generated files, in the middle of which sits my project. At least Java, for all its many faults, has the good sense to let you store dependencies nested as JAR files in a subfolder, as opposed to turning your own project into a dependency.

I have tried fixing this by symlinking my project into $GOPATH/src/whatever, but Go doesn't let me to run "go" commands on things outside the $GOPATH, which makes this rather painful to do in a shell.

Adding to the general confusion, Go doesn't manage canonical package paths, so github.com/zenazn/goji/main.go is in the package "goji" and github.com/zenazn/goji/graceful/[asterisk].go are in the package "graceful", but those package names only mean something to the importer. When "goji" wants to use the package "graceful", it imports "github.com/zenazn/goji/graceful", which, being a full URL, must be resolved from a root folder in GOPATH/src.

At least Java (for all its... etc.) had the good sense to make dotted package names mirror the folder structure of a project, not URL, thus being internally consistent. Go wants everything to live in the same sea of things. Vendoring is just half the problem.

Re: Problems with Go Get

#19
post #9

I haven't written much go, so I'm just riffing here, but could you do something similar to what the author is suggesting with git submodules?

I think this is a perfect use case for `git subtree`[0]. It actually pulls everything in-repo, but can squash their history and do some other conveniences. I've always been surprised at its relative obscurity – maybe because of a terminology conflict with "subtree merges" – because it's so useful. I haven't actually used it for go dependencies, but it seems like it would be a good fit.

[0]: https://github.com/git/git/blob/master/contrib/subtree/git-s...

Re: Problems with Go Get

#20
At work we have a monolithic repo containing Java, Go, Python, etc, organized like this:

  Java //src/com/yext/..     
  Go   //gocode/src/yext/...
GOPATH is set //gocode. .gitignore allows us to track only our code under the GOPATH using this snippet:

  /gocode/bin/
  /gocode/pkg/
  /gocode/src/*/
  !/gocode/src/yext/
We use glock[1] to sync dependencies across the team, without having to check them in.

The whole thing works very well at 50 developers and ~100 dependencies.

[1] https://github.com/robfig/glock

Post reply on HN