support vendoring

[nightlyone]

In a project using vendoring, I cannot use the vendored copy of godog.

Steps to reproduce:

• have a project in a single repostory with 3 directories:
  ** "foo" the package implementing things
  ** "features" where I have my *.feature files and step_test.go
  ** "vendor" where I vendored all my dependencies using govendor add '+all,^vendor,^local,^std' using https://github.com/kardianos/govendor (including "github.com/DATA-DOG/godog")
• now remove godog package via
  rm -rf $GOPATHsrc/github.com/DATA-DOG/godog
• trying to run godog ./features/*.features leads to

# _/tmp/godog-1465317047292377579
godog_runner_test.go:4:2: cannot find package "github.com/DATA-DOG/godog" in any of:
    /usr/local/go/src/github.com/DATA-DOG/godog (from $GOROOT)
    GOPATH/src/github.com/DATA-DOG/godog (from $GOPATH)
FAIL    _/tmp/godog-1465317047292377579 [setup failed]

It also doesn't work, when I go to the "features" directory and run godog *.features as well.

[l3pp4rd]

indeed, sadly build.ImportDir stdlib function does not list vendor dependencies detected, hope it will in next versions. will implement it the manual way, thanks for noting..

[l3pp4rd]

well, this one requires some changes in build process. will need to think on this to find better ways for implementation. for now you can depend on GOPATH vendored package, since it is a test dependency it should not be critical to production.

[pyrossh]

I guess vendoring still doesn't work,
This is the error I get after vendoring the dependencies

failed to compile testmain package:
/tmp/go-build862242248/playlyfe.com/go-potential/features/_test/_testmain.go:12: cannot use suite (type *"github.com/DATA-DOG/godog".Suite) as type *"playlyfe.com/go-potential/vendor/github.com/DATA-DOG/godog".Suite in argument to main.FeatureContext

[l3pp4rd]

hm interesting, which version of go? and did you have godog in vendor?

[l3pp4rd]

do you still have godog in GOPATH? it could conflict

[l3pp4rd]

if you rename the import to github.com/DATA-DOG/godog it should work fine. I'm trying to reproduce it now

[pyrossh]

When I'm importing the suite library, I'm doing so from the vendored package,

package main

import (
    "github.com/DATA-DOG/godog"
)
func FeatureContext(s *godog.Suite) {
 //some stuff
}

But when I run the godog tool, I guess you are creating a *godog.Suite from the binary and its a different package.
I'm using,

go: 1.6.2

And I have godog in vendor

[pyrossh]

Wait I removed It just now from the GOPATH

do you still have godog in GOPATH? it could conflict

Godog version is: v0.5.0

This is what i get now?

failed to find godog package in any of:
/home/pyros2097/Code/src/playlyfe.com/go-potential/features/vendor/github.com/DATA-DOG/godog
/usr/lib/go/src/github.com/DATA-DOG/godog
/home/pyros2097/Code/src/github.com/DATA-DOG/godog

I think I have to run the godog tool from the directory which contains the vendor directory and not in the features directory? Since its searching there?

[l3pp4rd]

The path is not valid: /home/pyros2097/Code/src/playlyfe.com/go-potential//features/vendor/github.com/DATA-DOG/godog there are two slashes

[l3pp4rd]

maybe your GOPATH ends with / slash? probably need to trim it on my Build script

[l3pp4rd]

could you echo $GOPATH to be sure

[pyrossh]

Opps That was a typo I fixed it,

[pyrossh]

echo $GOPATH /home/pyros2097/Code

[pyrossh]

It works when I run godog from the project folder,
/home/pyros2097/Code/src/playlyfe.com/go-potential/ since it could find the dependencies,
But then I had to move my main.go and main_test.go files to my main project folder from the features folder, so that it doesn't ask me to implement step definitions.

[l3pp4rd]

well, currently godog works exactly from the directory you are testing. you have to run it from the package being tested and having _test.go files there. it may be a little different compared to cucumber ruby. but the point is that, in go packages are isolated as a separate set of features. godog tries to follow that isolation and works at the package level. it can access everything what the tested package can with it's public or private interfaces.

[l3pp4rd]

could you list me your directory structureand file layout, so I could analyze whether we can change something. For example a basic package test with godog..

[l3pp4rd]

in general, godog works like go test except that for grammar it uses feature files.. hope it makes sense? :)

[pyrossh]

Yeah .. I think it was directory structure, I had trimmed the path the go-potential/features to reduce the long line and thats where the typo came into being,
I had the features actually like this,

go-potential/common/types/catalyst/features/quiz.feature
go-potential/common/types/catalyst/features/main.go
go-potential/common/types/catalyst/features/main_test.go

If I run it like this it doesn't work,

go-potential/common/types/catalyst/features/ $ godog 
failed to find godog package in any of:
/home/pyros2097/Code/src/playlyfe.com/go-potential/common/types/catalyst/features/vendor/github.com/DATA-DOG/godog
/usr/lib/go/src/github.com/DATA-DOG/godog
/home/pyros2097/Code/src/github.com/DATA-DOG/godog

So the way I was running it was like this to make it work after moving the main files to the topmost parent,

go-potential/ $ godog common/types/catalyst/features/quiz.feature

and then it could find the vendored packages,
I think it tries to find the vendored package from the subpackage folder, and not from the parent package folder,
because if a run a test with go test in features folder which has a vendored dependecy it works.
And BTW is that fish shell your using?

[l3pp4rd]

OK, I'll have a look someday later. but as far as I can tell, godog looks only into vendor directory from where it runs. godog itself uses godog to test itself, it could be a fine example from usage point of view.
My shell is zsh terminal st from suckless.org, fonts inconsolata solarized theme. dwm stands as window manager with a golang statusbar :)

[nightlyone]

I can confirm that I see the same @pyros2097 with v0.5.0 and tested with Go 1.6.2 and Go 1.7Beta1.

[nightlyone]

@l3pp4rd could you re-open this issue or should I move it to a new one? It doesn't seem to be solved for me.

[l3pp4rd]

I'll explain it in more details. I think you are using godog with unintended layout.

Expected godog usage

Given you have an API service package named: api
And the following directory layout:

$GOPATH/api/
  api_main.go
  api_context_test.go
  features/
    api.feature
  http/
    router/
      subpackage_dependency.go
  vendor/
    github.com/DATA-DOG/godog

When you run godog, even without any go files
Then it will work as expected, showing the snippets for step definitions or running them if there are go files with definitions in test files.

Imagine it as using go test command at the package level. features directory should contain only gherkin files describing your package features.

Other sub packages are compiled together as dependencies. but godog (same as go test) does not have any visibility over test files.

Your usage

$GOPATH/api/
  api_main.go
  features/
    api.feature
    api_context_test.go
  http/
    router/
      subpackage_dependency.go
  vendor/
    github.com/DATA-DOG/godog

You create another package features (which in terms of go) is a separate package. Maybe it make sense to look for it's dependencies and look for godog in their vendor directories. In this case api package. But if you would not have any go files but only gherkin features described in features directory. It will be impossible for godog to know where to look for it's package. since it is in parent/vendor directory which is not included anywhere at this stage.

In my opinion, having a separate features package does not conform to practices I would like to promote because of reasons mentioned above.

$GOPATH/api/
  api_main.go
  features/
    api.feature
  http/
    router/
      subpackage_dependency.go
  vendor/
    github.com/DATA-DOG/godog

In this situation it would just be not possible to run godog inside features directory to generate snippets. What is your opinion?

[l3pp4rd]

@nightlyone we can implement the behavior you expect, but godog will not be fully functional for such support. If you still think that it is reasonable then we can open a separate issue

[nightlyone]

thanks @l3pp4rd for making this clear!

May I suggest to error out when you have *.go files in the same directory as *.feature files? I thinks this leads to confusion for people not from ruby.

That might also be easier than making the other style work.

[l3pp4rd]

I'll probably update a general example instead. because you may have *.feature files in root or other directory based on your preference. We cannot determine whether it is as a bad usage case that easy. In some cases if it is a small package it may make sense to have no features directory at all but only package.feature file for instance.

In go we have a package level isolation, which we should respect in my opinion. even go test if run recursively runs each package separately. Godog so far does not have a recursive option, but there might be an implementation later to support that.

[nightlyone]

I'm sorry @l3pp4rd, but even with pure features directories it still doesn't work.

So I Built an isolated test-case using vendoring at https://github.com/nightlyone/godog-issue for you to play with.

I don't know what I'm doing different than you.

[l3pp4rd]

I made two versions in separate branches: see https://github.com/l3pp4rd/godog-issue

And with subpackage

[nightlyone]

ok @l3pp4rd there seem to be something funny about finding the vendored copy. With this minimal changes the testcase works beautifully without any changes:

diff --git a/builder.go b/builder.go
index a43fa9a..7802068 100644
--- a/builder.go
+++ b/builder.go
@@ -58,6 +58,11 @@ func Build() (string, error) {
                return "", err
        }

+       absup, err := filepath.Abs("..")
+       if err != nil {
+               return "", err
+       }
+
        bin := filepath.Join(abs, "godog.test")
        // suffix with .exe for windows
        if goos == "windows" {
@@ -130,7 +135,7 @@ func Build() (string, error) {
        // but we need it for our testmain package.
        // So we look it up in available source paths
        // including vendor directory, supported since 1.5.
-       try := []string{filepath.Join(abs, "vendor", godogImportPath)}
+       try := []string{filepath.Join(abs, "vendor", godogImportPath), filepath.Join(absup, "vendor", godogImportPath)}
        for _, d := range build.Default.SrcDirs() {
                try = append(try, filepath.Join(d, godogImportPath))
        }

I guess a full implementation needs to implement directory traversal upward until "src/" is hit or the workdir is reached.

[l3pp4rd]

OK I see that this is an issue to you, I'll update the library even if it is not the way I would like godog to be used.. but anyway hope that will solve it for good.

[l3pp4rd]

this should make you happy @nightlyone :) I'll tag it with 0.5.1 soon

[nightlyone]

Works like a charm now! Many thanks @l3pp4rd 👍