Workspaces and versioned dependencies

[Peregrinati]

So, about a year ago I wrote a toy go program. It worked beautifully then and was fun to write, it relied on package X. The way I had my GOPATH set up, anything I used 'go get' to obtain would end up somewhere outside of my home folder (I think it was in /opt/go/) while anything I wrote was under /home/ME/code/golang/. The latter directory was all I comitted to my repo (and hence backed up), since I thought anything else my package depended on, like package X, could be retrieved easily by 'go get'ting it again.

Obviously, that was a rather naive idea; as you might have guessed package X has changed significantly since then. After wiping my computer and restoring my repo, the toy program fails to build since package X is so different. So... what's the standard procedure for preventing this kind of problem? The "How to Write Go Code" document briefly says that multiple workspaces (separate entries in GOPATH) are nice, but doesn't explain how to use them effectively.

Back when I wrote that, I was trying to run two workspaces; one for third-party stuff and one to contain all the code I wrote (note: not just the one project). I can see now that that was a silly split, and that my code and package X should be in the same workspace and that both should be committed/backed up. That also has problems though... for instance what if 

My first thought was to get rid of the extra GOPATH workspace I had put in /opt/go/ for third-party packages and just have one, and commit everything in it. I don't like that for a few reasons: 

1. Everything, even totally unrelated projects, in one repo just feels wrong.
2. How do I handle new projects, in which perhaps I'd like to use a newer version of package X?

So... what's the recommended approach? All I can think of is changing my GOPATH whenever I change projects, and checking in each all the third-party libraries it depends on for each one. That seems kind of clunky though...

[Andrew Gerrand]

On 12 May 2013 21:10, Peregrinati <ben.b...@gmail.com> wrote:

what's the recommended approach?

Update toy to use the newer version of the library.

Andrew

[Tamás Gulácsi]

Maybe I don't get it right, but your main problem seems to be bit rot. You need a library version pinned to some past version.
The GOPATH dance won't fix this.

If you can get that past version by any way, than placing it to GOPATH/src/names/... will work (neither import, nor go get will change this version).

Another solution is to save all needed libs in your tree.

[Hotei]

The assumption that everything should end up in one big lump is not a good one.  Just leave the stuff you 'go get' in the other directory - and back it up.  In makefile below AlienGO is the  'go get' stuff, (first entry in my $GOPATH). src is my own code and is second entry.  Backups usually involve "make clean;make neat;make tar"  Tarballs are currently running about 300 MB so 100 of them will fit on a 32 GB flash.  Quick - Easy.  I also make a backup of $HOME/go when major version changes occur.

# MYGO makefile

TARNAME := allgo

GOVERSION := 1.1.0

TARDIR := $(HOME)/Desktop/Tarpit/

DATE := `date "+%Y-%m-%d.%H_%M_%S"`

TARBALL := $(TARDIR)$(TARNAME)_$(GOVERSION)_$(DATE).tar

# ===================================================================

world:

echo expect errors in zipxplode

go build ./...

clean:

go clean ./...

find . -type f -name "*~" -delete

neat:

go fmt ./...

tar:

echo $(TARBALL)

tar -cvf $(TARBALL) ../AlienGO src MyNotes Makefile

[Jesse McNelis]

And complain to the author of the library if they keep breaking the API.

If the API is still greatly fluctuating then it might be a bad idea to depend on it until it's more stable.

[Peregrinati]

Thanks for all the suggestions. I guess backing up -anything that looks like it might not be stable-(strike that) everything is a good idea (Captain Obvious strikes again! :P).

I'm still a little confused about the intended use of multiple workspaces (multiple paths in GOPATH) though. I mean "do what works best for you" is almost always good advice, but was my original split (homegrown vs thirdparty) something a lot of people do? Or is it common to take it a step farther and have a thirdparty space, plus one for each project? Why?