4 ms·
Vendoring is the way to go, but it done in a very awkward way here. I find it is better to just fork the repos you depend on and reference your fork. This makes
by voidlogic 12y ago
Vendoring is the way to go, but it done in a very awkward way here. I find it is better to just fork the repos you depend on and reference your fork. This makes it very easy to update them from upstream and eliminates any need for third party code in your repo.
Using the command line args is great for programs with small configs, but we find good old INIs and JSON to work better for large complex configs.
I think the deploy step outlined should be running the unit tests with the race detector enabled.
- lobster_johnson 12y agoSince an import cannot reference a specific tag or commit, even with forking you're exposed to the situation where a team member may update the fork and break the project. Keeping dependency information external to the project is a bad idea. So with forking, you still have to reference a "vendor" path, as described in the linked article. You could use Git submodules or Git subtrees, or something homegrown, all of which add complexity and are not ideal.
- jmoiron 12y agoThe way you describe it ends up being more awkward, because you have to change code to reference the new path, both in your own code, and potentially in the library you've forked and other dependencies that use it. Vendoring by just maintaining a GOPATH for your dependencies that you control is the preferred way.