thecodeteam / gorackhd Goto Github PK

My question here is stemming from #10. when working on github.com/codenrhoden/rackhdcli, I had originally started by working with gorackhd directly. Because of that, I had previously go install'd it.

To use gorackhd, you have to go install it, then do a make to generate the clients with go-swagger. When you run make, gorackhd uses glide to grab its dependencies and throw them in gorackhd/vendor.

At first I went down a path that let me to #10, whereby I was no longer using Glide in my project and was counting on having previously go install'd gorackhd. I had forgotten how I got there, and @clintonskitson pointed out that was the wrong way to do things. I do need to use Glide and have gorackhd in there as my dependency.

However, now I'm stuck on what to do next. If I use Glide to install gorackhd, it is not going to run make for me. I'd still have to run make manually (or add it to a make in rackhdcli, which seems less than ideal). In the end, I'm not seeing how I can ever do go install rackhdcli and get something working as long as that make step is in there.

On a side note, if I go into my resulting vendor'd copy of gorackhd and run make, I still end up with a second vendor directory and end up with mis-matched types. But I think this is an additional result of the make process.

Just for clarity, here is my glide.yaml:

package: github.com/codenrhoden/rackhdcli
import:
- package: github.com/emccode/gorackhd
  subpackages:
  - client
- package: github.com/emccode/gorackhd-redfish
  subpackages:
  - client
- package: github.com/spf13/cobra
- package: github.com/spf13/viper

Am I doing this completely wrong?

The current implementation requires the user to authenticate externally. The client should support local username and password authentication.

Right now, the current design of the RackHD Monorail Client (nested structs) is not mockable in dependent applications.

In order to test the client with mocks, it would be helpful to implement each of the APIs as methods (Nodes(), Catalogs(), etc.) and create a Monorail client interface. Then we could create an interface for each of the cilent endpoints -- a Nodes interface, Catalogs interface, etc.

I noticed today that the generated client code wasn't using the vendored version of go-swagger. When doing a make, I would see:

go run /Users/travis/go/src/github.com/go-swagger/go-swagger/cmd/swagger/swagger.go generate client -f swagger-spec/monorail.yml

But I expected to see:

go run vendor/github.com/go-swagger/go-swagger/cmd/swagger/swagger.go generate client -f swagger-spec/monorail.yml

I expected this because we are vendoring go-swagger to get a specific version. However, looking at commit history, I see that @akutz did this on purpose in 3c0f1fb. The intent was to go use go-swagger out of the GOPATH, as it fixes some invalid import paths that get put in when using a vendored go-swagger. To quote:

files generated using a vendored
version of swagger would be corrupt, containing incorrect import paths.
This fix changes the behavior of glide to copy vendored packages during
the first phase of the build process into the standard GOPATH structure.
Then the bindings are built by executing the swagger command's source
file using go run from inside the GOPATH structure.

However, it does not appear that Glide sets the version of go-swagger in $GOPATH as called for in the YAML file.

Here is an example, using the current master branch:

[travis@mbp ~/go/src/github.com/emccode/gorackhd (master)]$ make clean
rm -fr glide.lock .go.get cover.out client models
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ make clobber-gopath-swagger
rm -fr /Users/travis/go/bin/swagger
rm -fr /Users/travis/go/src/github.com/go-swagger/go-swagger
rm -fr /Users/travis/go/pkg/*/github.com/go-swagger/go-swagger
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ cat glide.yaml
package: github.com/emccode/gorackhd
import:
  - package: github.com/go-swagger/go-swagger
    ref:     6b712512cbe1f1a4882354856b57c61d760499cc
    vcs:     git
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ cat glide-swagger.yaml
package: github.com/emccode/gorackhd
ignore:
- client
- models
import:
  - package: github.com/go-swagger/go-swagger
    ref:     6b712512cbe1f1a4882354856b57c61d760499cc
    vcs:     git
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ make
....
....
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ pushd vendor/github.com/go-swagger/go-swagger/
~/go/src/github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger ~/go/src/github.com/emccode/gorackhd
[travis@mbp ~/go/src/github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger ((6b71251...))]$ git status
HEAD detached at 6b71251
nothing to commit, working directory clean
[travis@mbp ~/go/src/github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger ((6b71251...))]$ popd
~/go/src/github.com/emccode/gorackhd
[travis@mbp ~/go/src/github.com/emccode/gorackhd (master *)]$ pushd ../../go-swagger/go-swagger/
~/go/src/github.com/go-swagger/go-swagger ~/go/src/github.com/emccode/gorackhd
[travis@mbp ~/go/src/github.com/go-swagger/go-swagger (master)]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Note that go-swagger in the $GOPATH is on master. That's not what we were after.

The command we expect to do this for us is /Users/travis/go/bin/glide --home /Users/travis --yaml glide-swagger.yaml up --quick --cache-gopath --use-gopath

--cache-gopath will copy the git repo from the $GOPATH into vendor if it's there.
--use-gopath will also download a dependency into $GOPATH (presumably to take better advantage of caching). But, AFAICT this does not set the version. And truthfully I don't think it should. Glide is for managing deps in the vendor dir, I wouldn't want it changing versions of repos in my $GOPATH...

So either (1) this is a bug in Glide and it should set that version (I don't think it should) or (2) this approach doesn't quite work.

I'd be curious to know more about what issues were hit when generating the client from the vendored version of go-swagger. I had edited the Makefile locally to use the vendored version instead, and the code looked fine. All tests passed, but those aren't exercising a whole lot. Is there any advice on how I could look if those invalid import paths are still being generated? Because if they aren't, we can simplify this whole thing by using the vendored version again.

FYI, I had pushed a branch, fix/use_vendored_swagger that uses the vendored go-swagger instead, but that was before I found the history. The cleaner way to structure the Makefile would be to put it how @akutz had it before adding the GOPATH swagger.