5 ms·
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 y
by codetrotter 8y ago
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 8y agoSure, 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.