make exercism binary "go get"-able

[nf]

See the second section of this article: http://blog.golang.org/organizing-go-code

It would be great to be able to type "go get github.com/msgehard/go-exercism/exercism" to build and install the command line tool.

To handle the external dependencies, check a copy of them into your repo under third_party/foo, and rewrite the import paths. This is the approach we take internally at Google and in the camlistore.org project. It means you don't need to mess around with git sub-repositories either, which is either a plus or a minus depending on how you look at it.

[kytrinyx]

That's excellent, thank you!

[kytrinyx]

I got myself stuck. Assuming that third_party is a user on github, should that be:

$GOPATH/src/github.com/$ME/$PROJECT/github.com/third_party/foo

Or rather:

$GOPATH/src/github.com/$ME/$PROJECT/third_party/foo

And then when I import it, do I reference it as though it were still the github.com/third_party/foo that I go getted (uhm. go got?) or is it the path on relative to $GOPATH/src within my project?

On a related note, is there a blog post that discusses dependency management (pros? cons? pains? gotchas? religious wars?)?

[nf]

I think you want this one

$GOPATH/src/github.com/$ME/$PROJECT/github.com/third_party/foo

and then your import statement is something like

import "github.com/$ME/$PROJECT/github.com/third_party/foo"

It's long, but it'll work. You can reduce it down if you like, one possibility:

$GOPATH/src/github.com/$ME/$PROJECT/ext/foo

with the import

import "github.com/$ME/$PROJECT/ext/foo"

There's no hard-and-fast rule as to how it should be done, but this method is easy to understand and works well. (It's how we handle open source stuff internally at Google.)

There is no small amount of consternation about this in the Go community, mainly because people really don't like copying and pasting code. From many corners there are calls for more automated solutions. So far we (the Go team) have resisted building some mechanisms to handle the versioning stuff, because fundamentally the problem is intractable and we can't see a solution that would work well for most people.

Nathan Youngman produced a good doc explaining the situation. It's also a call-to-arms to the community to sort their shit out. I think the dependency management situation will improve through a combination of documentation and tooling, but I'm not sure what the final solution might be.

[kytrinyx]

My biggest concern is figuring out what a good/acceptable convention is, and then sticking with it. My second biggest concern is not putting my foot in my mouth with respect to a complicated, emotional topic.

Thanks for the help with both of these :)

[diimpp]

You probably want to automate it.
https://github.com/kr/godep
https://github.com/gopack/gpk

[kytrinyx]

You probably want to automate it.

Would you elaborate please? At the moment, if someone clones the repository and says go get, this should get the dependencies. Clearly I'm missing something.

[nf]

The suggestion is to clone your dependencies inside the repository to avoid
version skew. I don't think this is necessary, though. Let's wait and see
if there are actually any issues.

Andrew
On 29 Oct 2013 23:42, "Katrina Owen" notifications@github.com wrote:

You probably want to automate it.

Would you elaborate please? At the moment, if someone clones the
repository and says go get, this should get the dependencies. Clearly I'm
missing something.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-27299308
.

[kytrinyx]

Ah, thanks for clarifying. Yes, I'm going to stick with this unless there are actual problems.

[kytrinyx]

Actually, now that I think this through, I think this issue can be closed. Thanks for the help, everyone!