Feature/batch script execution

[darvin]

#147

[darvin]

should expreduce/resources.go be gitignored?..

[corywalker]

Hi @darvin ,

This was initially the case, but after releasing 0.1, I noticed that people were having issues with the go generate steps. This meant they could not easily "go run expreduce.go". In the end, cznic and I decided to include generated Go source in the repo. Context here:

#40

You're right that this will cause merge conflicts to happen often on resources.go, something I did not consider. Perhaps a simple fix would be to have a separate resources.go for each module, reducing the chance of this. Optionally an idea would not be to have this resources.go and somehow load the files directly. Not sure if there is a standard way to do this with Go packages.

For now I'd recommend merging in changes from master and then regenerating resources.go. If it gets unmanageable we can implement one of the above solutions, or even gitignore resources.go.

-Cory

[corywalker]

The changes in this PR look great though. Thanks for this change. I can merge after you address the conflict on resources.go.

[darvin]

addressed

[darvin]

offtopic, but have you considered using dep for dependency management/build system? I'm super new to golang, but it seems like something that would solve this problem (and much more)

edit: maybe not, I just would imagine package manager would have "pre install" step where you can generate things

[corywalker]

I'm reading up on dep. It does seem to be used by some popular Go projects now. Not sure if it would help with the generated code issue, but it could help with managing versions of dependencies.

[cznic]

Suggesting vgo instead.

[darvin]

(I have no opinions on dep specifically, im total complete Go noobie :) )