The typical use of goop is to have a Goopfile (and .lock) at the root of a project. Running goop install creates a .vendor in the project directory wherever the Goopfiles are defined.
A pattern that I like, started by Ben Johnson, is having a cmd directory that is actually the main package of the project to create the cli binary. This is a good pattern because it encourages writing your project as a library that can be imported by others. As a simple example see: https://github.com/boltdb/boltd
Now when the current working directory is $GOPATH/src/github.com/boltdb/boltd/cmd/boltd .. and then running goop go build it would be nice for goop to go up the chain until it finds the first Goopfile/.lock/.vendor and use that namespace.
Hope that makes sense. Otherwise this means you have to run goop in the root of the project everytime, which is fine but this isn't clear. The downside of searching the children is when do you stop, in case someone forgets to have a Goopfile somewhere ... but, maybe that isn't so bad.
The typical use of
goopis to have a Goopfile (and .lock) at the root of a project. Runninggoopinstall creates a.vendorin the project directory wherever the Goopfiles are defined.A pattern that I like, started by Ben Johnson, is having a
cmddirectory that is actually themainpackage of the project to create the cli binary. This is a good pattern because it encourages writing your project as a library that can be imported by others. As a simple example see: https://github.com/boltdb/boltdNow when the current working directory is $GOPATH/src/github.com/boltdb/boltd/cmd/boltd .. and then running
goop go buildit would be nice forgoopto go up the chain until it finds the first Goopfile/.lock/.vendor and use that namespace.Hope that makes sense. Otherwise this means you have to run
goopin the root of the project everytime, which is fine but this isn't clear. The downside of searching the children is when do you stop, in case someone forgets to have a Goopfile somewhere ... but, maybe that isn't so bad.