allow to run glide commands in a directory other than PWD

[dmitris]

With go toolchain, you can issue a command like go install github.com/Masterminds/glide from any directory - you don't have to cd $GOPATH/src/github.com/Masterminds/glide beforehand which is convenient for example for the automated build systems or scripts. Would it be possible to enable something similar in glide where you could decouple the target directory (with glide.yaml / glide.lock files) and your current pwd?

I realize that because of the way the current "glide get" works, it may not be feasible to allow glide init <target_package> - but maybe it would be possible to add a global --target option - then glide init --target=github.com/me/myproject would mean to run the glide init in $GOPATH/src/github.com/me/myproject.

If you like the idea, I could take a look at implementation and send a PR.

[mattfarina]

@dmitris I'm open to the idea. I would ask that you wait on a PR until we finish the feat/no-cookoo branch. We are cleaning up the internal architecture right now to make it easier to contribute and remove legacy code.

[james-lawrence]

+1 was coming to make a request for this feature myself.

[technosophos]

We could do this a few ways:

1. We could require the user to specify a target directory
2. We could walk backwards up the directory structure until we hit a glide.yaml file
3. We could parse PWD and try to figure out where we are in relation to GOPATH

I suspect that (1) is too cumbersome for the user (but might be a nice additional option)

While (3) seems easy, it's actually a huge pain because GOPATH can have multiple paths in it, and because symlinked directories don't quite work as expected.

And (2) only suffers from one drawback: If you cd into a vendor subdirectory that has a glide.yaml file in it, that'll be the one that is modified instead of the one in your code. But I think that is probably an acceptable situation.

Am I missing any other methods?

[dmitris]

I would think that (3) is more in line with how the go tools usually work (GOPATH-based). I think it would be great to be able to specify the package as the target (such as github.com/foo/bar and make glide to translate it internally into the $GOPATH/src/github.com/foo/bar directory. If there is no target provided by the user, I would default to the current package as in the output of go list.

[dmitris]

I would disagree that GOPATH-based target is a big problem - I used go install <package> and go test <package> so many times, it is especially useful for build scripts and building/CI infrastructure. I guess I got used to Go's symlink aversion as a feature long time ago - maybe it indeed simplifies some things.

A big benefit of (3) is that is PWD-independent - as long as you specify the GOPATH, the current directory where you happen to execute the command is not important and you don't have to jump through the hoops of continuously doing OLDPWD=$(pwd) && cd $GOPATH/src/<package> && glide update && glide install && cd ${OLDPWD} but instead can be much less verbose and more to the point: glide update <package> && glide install <package>. Liberation from the current 'PWD oppression' is the main motivation of this issue (at least for me) :smile: