From 6d80ce514e3b2ec096d713ab6e448caa25c22dbf Mon Sep 17 00:00:00 2001 From: Brian Picciano Date: Thu, 11 Jul 2013 21:27:58 -0400 Subject: go+ --- goplus.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 goplus.md (limited to 'goplus.md') diff --git a/goplus.md b/goplus.md new file mode 100644 index 0000000..c9b0191 --- /dev/null +++ b/goplus.md @@ -0,0 +1,59 @@ +# Go and project root + +Compared to other languages go has some strange behavior regarding its project root settings. If you +import a library called `somelib`, go will look for a `src/somelib` folder in all of the folders in +the `$GOPATH` environment variable. This works nicely for globally installed packages, but it makes +encapsulating a project with a specific version, or modified version, rather tedious. Whenever you go +to work on this project you'll have to add its path to your `$GOPATH`, or add the path permanently, +which could break other projects which may use a different version of `somelib`. + +My solution is in the form of a simple script I'm calling go+. go+ will search in currrent directory +and all of its parents for a file called `GOPROJROOT`. If it finds that file in a directory, it +prepends that directory's absolute path to your `$GOPATH` and stops the search. Regardless of whether +or not `GOPROJROOT` was found go+ will passthrough all arguments to the actual go call. The +modification to `$GOPATH` will only last the duration of the call. + +As an example, consider the following: +``` +/tmp + /hello + GOPROJROOT + /src + /somelib/somelib.go + /hello.go +``` + +If `hello.go` depends on `somelib`, as long as you run go+ from `/tmp/hello` or one of its children +your project will still compile + +Here is the source code for go+: + +```bash +#!/bin/sh + +SEARCHING_FOR=GOPROJROOT +ORIG_DIR=$(pwd) + +STOPSEARCH=0 +SEARCH_DIR=$ORIG_DIR +while [ $STOPSEARCH = 0 ]; do + + RES=$( find $SEARCH_DIR -maxdepth 1 -type f -name $SEARCHING_FOR | \ + grep -P "$SEARCHING_FOR$" | \ + head -n1 ) + + if [ "$RES" = "" ]; then + if [ "$SEARCH_DIR" = "/" ]; then + STOPSEARCH=1 + fi + cd .. + SEARCH_DIR=$(pwd) + else + export GOPATH=$SEARCH_DIR:$GOPATH + STOPSEARCH=1 + fi +done + +cd "$ORIG_DIR" +exec go $@ +``` -- cgit v1.2.3 From 35f1708c1f59050b46b8ba387e2906755bfa73d5 Mon Sep 17 00:00:00 2001 From: Brian Picciano Date: Tue, 8 Oct 2013 22:26:08 -0400 Subject: gq and reference-style-link everything --- goplus.md | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) (limited to 'goplus.md') diff --git a/goplus.md b/goplus.md index c9b0191..e6d9f85 100644 --- a/goplus.md +++ b/goplus.md @@ -1,16 +1,19 @@ # Go and project root -Compared to other languages go has some strange behavior regarding its project root settings. If you -import a library called `somelib`, go will look for a `src/somelib` folder in all of the folders in -the `$GOPATH` environment variable. This works nicely for globally installed packages, but it makes -encapsulating a project with a specific version, or modified version, rather tedious. Whenever you go -to work on this project you'll have to add its path to your `$GOPATH`, or add the path permanently, -which could break other projects which may use a different version of `somelib`. - -My solution is in the form of a simple script I'm calling go+. go+ will search in currrent directory -and all of its parents for a file called `GOPROJROOT`. If it finds that file in a directory, it -prepends that directory's absolute path to your `$GOPATH` and stops the search. Regardless of whether -or not `GOPROJROOT` was found go+ will passthrough all arguments to the actual go call. The +Compared to other languages go has some strange behavior regarding its project +root settings. If you import a library called `somelib`, go will look for a +`src/somelib` folder in all of the folders in the `$GOPATH` environment +variable. This works nicely for globally installed packages, but it makes +encapsulating a project with a specific version, or modified version, rather +tedious. Whenever you go to work on this project you'll have to add its path to +your `$GOPATH`, or add the path permanently, which could break other projects +which may use a different version of `somelib`. + +My solution is in the form of a simple script I'm calling go+. go+ will search +in currrent directory and all of its parents for a file called `GOPROJROOT`. If +it finds that file in a directory, it prepends that directory's absolute path to +your `$GOPATH` and stops the search. Regardless of whether or not `GOPROJROOT` +was found go+ will passthrough all arguments to the actual go call. The modification to `$GOPATH` will only last the duration of the call. As an example, consider the following: @@ -23,8 +26,8 @@ As an example, consider the following: /hello.go ``` -If `hello.go` depends on `somelib`, as long as you run go+ from `/tmp/hello` or one of its children -your project will still compile +If `hello.go` depends on `somelib`, as long as you run go+ from `/tmp/hello` or +one of its children your project will still compile Here is the source code for go+: -- cgit v1.2.3 From 9624df51ec97b258da152d8807619c56104f7815 Mon Sep 17 00:00:00 2001 From: Brian Picciano Date: Tue, 8 Oct 2013 22:19:12 -0400 Subject: added in goat shoutout to go+ post --- goplus.md | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'goplus.md') diff --git a/goplus.md b/goplus.md index e6d9f85..58ab303 100644 --- a/goplus.md +++ b/goplus.md @@ -60,3 +60,14 @@ done cd "$ORIG_DIR" exec go $@ ``` + +# UPDATE: Goat + +I'm leaving this post for posterity, but go+ has some serious flaws in it. For +one, it doesn't allow for specifying the version of a dependency you want to +use. To this end, I wrote [goat][0] which does all the things go+ does, plus +real dependency management, PLUS it is built in a way that if you've been +following go's best-practices for code organization you shouldn't have to change +any of your existing code AT ALL. It's cool, check it out. + +[0]: http://github.com/mediocregopher/goat -- cgit v1.2.3