Allow the buffalo binary to use the version vendored with dep

[markbates]

If the following conditions then vbuffalo will attempt take over:

• The app MUST be using dep
• The vendor directory MUST exist

If those conditions then vbuffalo behaves in a similar fashion to grift. It will first create a new .grifter/main.go and use that to build a new binary, bin/vbuffalo that has been compiled using the vendored version of Buffalo.

Another requirement is this section in Gopkg.toml

[prune]
  go-tests = true
  unused-packages = true

  # DO NOT DELETE
  [[prune.project]] # buffalo
    name = "github.com/gobuffalo/buffalo"
    unused-packages = false

  # DO NOT DELETE
  [[prune.project]] # pop
    name = "github.com/gobuffalo/pop"
    unused-packages = false

For new applications the appropriate toml will be generated. For existing applications we will add the missing prune sections to their Gopkg.toml file if they don't already have them.

[markbates]

@stanislas-m @paganotoni would love to have on this at some point by either one of you. even better, play with it. :)

[paganotoni]

@markbates I will play with it tonight, do you have any suggestion on how to test it?

[markbates]

Just build the buffalo binary from the branch and use as normal. Report anything strange. See the notes about when it kicks in. You’ll know it’s working because it will print vXXX [development] at the top.

[markbates]

The idea is that it’s virtually seemless.

[paganotoni]

@markbates i just run it with my pre-productive app and seems to work 👌, as far as I can tell from the logs (and i'm assuming all this is expected behavior based on the code):

• If the project has dep it will use vendor buffalo version and generate a vbuffalo binary, which will be the one it will use to run the app and other things.
• if the project doesn't use dep it will use the version in the GOPATH.

I see both happening correctly if I remove my Gopkg.yml and re-add it.

[paganotoni]

@markbates do you think its worth to add some automated tests for this or is it too overkill at this level? (i would love to have some).

[markbates]

@paganotoni I would love some automated tests around it? any idea how to add them?

[paganotoni]

Probably in our Dockerfile, we could at least check the output of a dep project for buffalo version vs a non-dep project, but thats from the top of my head.

[paganotoni]

@markbates sorry if I'm overdemanding, I'm very excited about this, just by reading it learned a lot :)

[markbates]

@paganotoni lol, I appreciate the input actually. want to try and see if you can whip up a little something, even a smoke test in the docker file?

[markbates]

@paganotoni any idea why the file tests you added for this are failing?

[paganotoni]

@markbates not sure, what are your thoughts on printing something that let us know that we're running the version of dep instead of GOPATH version?

[markbates]

@paganotoni that was why I was printing version [version] at the top. but I'm happy if you want to change it to something a little better/easier.

[paganotoni]

@markbates find it, i'll update the PR soon :)