Review set of vendored deps.

[kad]

@cortesi please review set of deps that are part of vendor/ directory. This set is not enough to build devd without fetching something from the network, thus devd 0.5 in homebrew still proposed to be built in "old way": Homebrew/homebrew-core/pull/182

[cortesi]

Hi there. Thank you very much for keeping the homebrew release up to date! I wonder what the right way to go is here. I've vendored all of the external dependencies, so the only things that should need to be explicitly fetched in the homebrew script is cortesi/termlog and cortesi/modd. I don't see any sensible way around that. We can streamline this by synchronising the release numbers for all three packages (which are developed together anyway). Thoughts?

[kad]

I've tried to disable external dependencies in formula and fetch yours code via go_resource, but then I've got still errors during building, as it can't find properly vendor/* hierarchy. Might be something wrong with go.rice or something else (like my misunderstanding how it mixes paths during build), haven't found yet :(

Have you tried to build in some clean environment without network before ? Maybe I'm missing some setting, but didn't noticed it.

[kad]

with some dirty hack I was able to remove most of external deps:
kad/homebrew-core@c373d22

However, few of them still fetched in formula, as they are not present in vendor/

  go_resource "github.com/mitchellh/go-homedir" do
    url "https://github.com/mitchellh/go-homedir.git",
        :revision => "981ab348d865cf048eb7d17e78ac7192632d8415"
  end

  go_resource "github.com/toqueteos/webbrowser" do
    # v1.0
    url "https://github.com/toqueteos/webbrowser.git",
        :revision => "21fc9f95c83442fd164094666f7cb4f9fdd56cd6"
  end

  go_resource "github.com/alecthomas/template" do
    url "https://github.com/alecthomas/template.git",
        :revision => "14fd436dd20c3cc65242a9f396b61bfc8a3926fc"
  end

  go_resource "github.com/alecthomas/units" do
    url "https://github.com/alecthomas/units.git",
        :revision => "2efee857e7cfd4f3d0138cc3cbb1b4966962b93a"
  end

  go_resource "gopkg.in/alecthomas/kingpin.v2" do
    # v2.1.11
    url "https://github.com/alecthomas/kingpin.git",
        :revision => "8cccfa8eb2e3183254457fb1749b2667fbc364c7"

Does that look like a bug in way I'm building or those needed to be added under vendor/ ?

Another related topic: I was not able to run "go test", but that probably next battle :)

[cortesi]

Hey there. So, there's a bunch of related issues here. Lets see if we can improve this situation. I've just added the missing vendor dependencies (I overlooked the ones unique to ./cmd/devd). I'm also going to commit the compiled rice templates (fixes go get, simplifies the homebrew recipe). After that, the only external resources listed should be modd and termlog.

There's a broader issue to do with how vendoring works, which means that I'm going to split out the library component of modd out into a separate repo soon, which would replace the modd dependency here.

I'm also considering putting a script to generate the homebrew configuration straight in the repo. There's a handy wee tool called homebrew-go-resources that can auto-generate the inclusions for us. Thoughts?

[kad]

Yeah, overall dependency tracking in Go is hell at the moment :( It getting better with all tools added into ecosystem, but still can be classified as "hell" in my opinion :)
Helper tool to collect resources might be good, let's see how it works after you finish restructuring.
I'm ok with any solution.

[cortesi]

Yeah, agreed. @homburg sent me a link to the following interesting and slightly depressing discussion:

https://groups.google.com/forum/#!msg/golang-nuts/AnMr9NL6dtc/UnyUUKcMCAAJ

It's clear that we have a long way to go before we have enough consensus around the tooling to make vendoring fluid.

OK, I'll close this ticket because I think the vendor situation has now been fixed. I've also just committed the rice templates, so that step is now also un-necessary in the homebrew recipe.

[kad]

ok. I'll try HEAD tomorrow.

[cortesi]

Great. See the commit I just did with ./scripts/mkbrew. It's a work in progress, but I think heading in the right direction.

Hopefully we can just automate all of this and make homebrew releases less of a headache.