Vendor dependencies, add hacking guide

[s-urbaniak]

This PR vendors all OCI image spec Go dependencies using glide and glide-vc.

Additionally it adds a hacking guide since we accumulated quite some tools/prerequisites for various make targets. The hacking guide documents them.

Fixes #76, #162

[s-urbaniak]

@vbatts git-validation complains about blanks at EOF in vendored files:

vendor/github.com/pkg/errors/LICENSE:24: new blank line at EOF.
vendor/go4.org/LICENSE:202: new blank line at EOF.

Can I somehow tell it to ignore any files in vendor/**?

[wking]

On Thu, Jun 16, 2016 at 02:54:51AM -0700, Sergiusz Urbaniak wrote:

This PR vendors all OCI image spec Go dependencies using glide and
glide-vc.

Plugged in yesterday's Git Rev News 1: manul 2, which uses
submodules for vendoring. I'm unlikely to be a big Go consumer, and I
don't have meaninful personal experience with any Go vendoring tools,
but I thought I'd mention it because I don't like committing external
code to my own repositories ;).

[s-urbaniak]

Committing vendored code is quite idiomatic in Go. We do this in many other projects.

Using git submodules for vendoring has been tried before (including me) with mixed/bad results, see https://groups.google.com/forum/m/#!topic/go-package-management/KR2zrSIsRho for details.

[jonboulle]

I think we should just fix git-validation

On 17 June 2016 at 15:43, Sergiusz Urbaniak notifications@github.com
wrote:

Committing vendored code is quite idiomatic in Go. We do this in many
other projects.

Using git submodules for vendoring has been tried before (including me)
with mixed/bad results, see
https://groups.google.com/forum/m/#!topic/go-package-management/KR2zrSIsRho
for details.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACewN6zlXu2RL47EaRxOVj-rO5htzqkqks5qMqSBgaJpZM4I3N3y
.

[philips]

@vbatts please help with git-validation

On Fri, Jun 17, 2016 at 6:49 AM Jonathan Boulle notifications@github.com
wrote:

I think we should just fix git-validation

On 17 June 2016 at 15:43, Sergiusz Urbaniak notifications@github.com
wrote:

Committing vendored code is quite idiomatic in Go. We do this in many
other projects.

Using git submodules for vendoring has been tried before (including me)
with mixed/bad results, see

https://groups.google.com/forum/m/#!topic/go-package-management/KR2zrSIsRho
for details.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
#148 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/ACewN6zlXu2RL47EaRxOVj-rO5htzqkqks5qMqSBgaJpZM4I3N3y

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#148 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACDCPQn6oagwIwSxbIBwFCVSLvuDFjIks5qMqX7gaJpZM4I3N3y
.

[vbatts]

man. Since it is using git show --check ... I am not seeing a flag to ignore paths in that git command. Apart from wholly reimplementing this functionality outside of git, it may be faster to either
A) fix the offending issues in a correction commit
B) turn off the whitespace check for a bit

[wking]

On Tue, Jun 21, 2016 at 10:53:28AM -0700, Vincent Batts wrote:

A) fix the offending issues in a correction commit

I think the validator checks each commit, so you'd probably need to
patch the initial vendoring commit.

[philips]

I think we should just merge it :-/

LGTM

[s-urbaniak]

What a mess, I did some duck-taping to hopefully fix everything:

• Apply some sed-magic in the update-deps Makefile target to remove EOL's for each file in the vendor directory: ecb2556#diff-b67911656ef5d18c4ae36cb6741b7965R97

I am a bit worried whether this EOL-sed-fix will work on OSX though.

• Pinned gojsonschema to the last working version until upstream has a fix ready: ecb2556#diff-395f41b2a27b70ce44399c91c82158c2R11

@vbatts @philips PTAL

[vbatts]

@s-urbaniak are we concerned about OSX? 😉

[wking]

Probably better to use find's -exec instead of the for loop (-execdir is safer, but not in POSIX). Although you may have to keep the for loop, because -i is not in POSIX for sed.

[vbatts]

LGTM

[jonboulle]

LGTM (but do we need to worry about #148 (comment) ? I will leave it to @vbatts or one of the OS X users to merge)

[vbatts]

For loops are generally fine, though this would break if there were a path that had a space in it. That's generally frowned upon though 🤓.
As for the sed -i, I'm OK waiting until that is an issue.