[codetrotter]

Symlinks are your friends ;)

Keep the actual directory where Go wants it to be and create a symlink to it in ~/dev/$who/$project.

Next, create a script that you name as “mygo” or whatever (something short and memorable that makes sense to you. I would probably name it as just “g”) and put it in your ~/bin/ and ensure you have ~/bin in your $PATH.

In said script you resolve the real path of your project, cd there and then execute /usr/local/bin/go with the args that your script got:

    #!/usr/bin/env bash

    cd "$( realpath . )"

    /usr/local/bin/go "$@"

So when you are in ~/dev/someclient/someproject/, you run “mygo build” and the script runs “go build” from the real path of the project. (At first I suggested to name your script as just “go”, but I decided that it was probably better to use a non-colliding name instead and so I quickly edited this comment.)

That ought to do it.

I totally agree with you though. I do similar to you — I keep public projects under ~/src/github.com/ctsrc/$project and client projects under ~/src/$client/$project. If it wasn’t for the fact that I don’t write in Go I would be annoyed too.

[pdpi]

Sure, there's decent workarounds to solve this problem, but I take it as a general rule that, if I'm fighting against (rather than with) a tool, I'm either using the wrong tool, or I'm using the tool wrong.

If my fight against a language starts at the "I can't put my source code where I want without having to fight it", it's an uphill battle to convince me this is not a "using the wrong tool" scenario, and I'm happy to take my dev time elsewhere.