For quite some time, I have been wondering where to save resources for my go package and I just cannot find a correct answer.
Right now, resources are kept into
- main/module1/resources
- main/module2/resources
When I just use go run *.go from main, it works fine. When I run tests, however, the resources cannot be found because Go changes the current working directory to the corresponding module. One workaround is to just os.Chdir('..') but doing that for every test seems kind of annoying. Furthermore, sometimes the resources are loaded as the package initializes. That means there is a global map with all templates (and their corresponding names):
package module2
var myTemplates = map[string]template { "index": loadTemplateFromFile() }
I know you should not be using globals in go because of concurrency but this variable is safe for concurrent reads (and it is only written to during startup). So I put the templates into a global var so that they can be loaded on startup and some errors are caught during startup and the template are already in memory.
This means that I cannot change the working directory in time because the problem will already panic'd with an error telling me the file could not be found (this is the exact behavior I want).
Later, I discovered a method runtime.Caller to get the path from where the go files were compiled (if available):
base := "."
if _, filename, _, ok := runtime.Caller(0); ok {
base = path.Join(path.Dir(filename), "..")
}
file := path.Join(base, "module1", "resources", ...)
Now, all tests work just fine and go run *.go also finds the correct resources. This method becomes an issue as soon as I start deploying my package. Because runtime.Caller uses the path which was used during compilation, I have to have the resources in the excact same location where I complied them. This means when I build the binary in /home/matt3o12/go/src/domain.tld/matt3o12/mypackage, I have to have all resource folders at the exact same path on the server.
I also tried to use os.Executable but this is pretty pointless because it just points to some temporary path with the compiled executable inside (and no resources). Unless I compile a test package and run it manually but this is very work intense.
I am also not looking to store the resources inside the binary (having a folder structure of the project resources is just fine).
I do have some ideas to solve this problem but I don't think any of them are optional:
- Use a flag to point to the resource folder. This would work but using that for every test I run would be pretty annoying (because now everytime I use
go test ./...orgo run *.go, I have to worry about the proper resource path). - Use "magic" to figure out if tests are run and change the path accordingling. I would hate to use that because I would have to place those checks all over my code and I hate to have many "edge/special" cases.
This is not a duplicate of:
