Dependency binaries not building? about gpm

[pote]

It's done on purpose! It's the -d flag we use when we call go get.

The reason for it is: whenever packages are installed with go get they generate the binary right after installation, which means that all your packages will be built with whatever version is HEAD, as packages are still installing and haven't been set to their corresponding versions, this means the binaries will not be built according to what you specify in Godeps.

Unfortunately there's no real way around it other than running another command to create the binaries after the packages are installed and set to their corresponding versions. We've left it out of gpm as adding code for that would be overkill, taking into account binaries will be built whenever a user runs any go command. :)

[leeola]

Good point!

With that said, what do you think would be the most harmless (read: no side affects) way to create the binaries? This sounds like a quick and simple gpm plugin :)

[pote]

Good question! I'd have to try. Maybe something as simple as go install ./... would do the trick? I'd have to play around with the different go tool commands to be sure. :)

[pre]

I ran into this very issue with goconvey.

Any best practices how to gpm install to get both goconvey sources AND bin/goconvey ?

I'm looking for a solution that would work across a team, so that there wouldn't be a requirement such as "you need this one extra go get after gpm install" :)

[leeola]

Well as pote said, go install foo works quite well. I'm not sure what you could do for your Team (if you want to distribute plugins or not), but my thought process originally was to have a way to signal libraries that needed binaries, and automatically run go install foo after the library was checked out by gpm. This signal could be a Godeps.bin file (a special file, for just binaries), or a syntax within the normal Godeps file that you make up.

Depending on how many binaries you need though, a plugin may be overkill - as was my experience. I just use go install foo manually. :)

[pote]

Well, actually gpm starting running go install for all dependencies not too long ago! :)

This really depends a lot on how people install things and what their setup is, what does your GOPATH look like @pre ? what version of gpm are you on? Do you install goconvey in the same place you install your project dependencies? go install has some quirks on binary creation depending on GOPATH setup.

[pre]

gpm version 1.3.2

I use gvp to get project-independent packages. Packages are installed under project_dir/.godeps
I have github.com/smartystreets/goconvey/convey master in Godeps.

After gpm install everything else is installed except .godeps/bin/goconvey. When I manually run go install github.com/smartystreets/goconvey, then .godeps/bin/goconvey will be created.

Problem is reproduceable by first removing the deps with rm -fr .godeps and redoing the steps above.

As a workaround, I created a Makefile task:

deps:
  bash -c "source gvp && gpm install && go get github.com/smartystreets/goconvey"

It's not optimal, but since goconvey is currently the only dependency with binaries, this allows installing all the dependencies with one command make deps.

[pre]

I'M SORRY GUISE...

Right after posting the comment I saw the typo there, should have github.com/smartystreets/goconvey in Godeps (had one extra /convey there).

K THX BAI

[pre]

(it is still funny that the dependency was otherwise installed without errors using the incorrect path, only the binaries went missing....... )

[pote]

it definitely is funky, gpm has flags set to ensure it aborts execution if any of the commands return a non-success status code.

The extra /convey is making go install compile the convey package into $GOPATH/pkg and ignore everything else, meaning a successful exit code and no errors in gpm, it makes sense I guess.

I'm glad the problem it's fixed for you! closing the issue again, thanks everyone! :)