first commit

[azylman]

I thought about getting rid of the test CSVs and instead using buffer data in the test file, but this ended up being convenient for running the command line tool against, as well.

[schimmy]

The main thing I'm thinking about is stderr / stdout and exit codes - I think all the stuff being output right now should be output via stderr. I could imagine this program printing out the invalid lines to stdout in the future, for instance. I could see this (and the 'is valid') still printing to stdout, perhaps:

for _, invalid := range invalids {
    fmt.Println(invalid.Error())
}

Also, we should exit with non-zero (and non-1 to distinguish from the other error cases) when the csv fails validation - that way scripting this will be easier.

I'm a little concerned that there are some other tools for this - specifically, we could use something which has a csv schema potentially, and really tighten up what we accept.

[azylman]

Why stderr? The point of the program is to tell you whether or not a CSV is valid, and why, so that information doesn't seem like "debug" output, it seems like expected output of the program.

Agree about this, though: "we should exit with non-zero (and non-1 to distinguish from the other error cases) when the csv fails validation - that way scripting this will be easier"

I looked into alternatives before I started and there are two of them, one written in JS and one written in Ruby.

The one written in JS doesn't have any documentation and no one uses it (no watchers on Github).

The one in Ruby looks pretty sweet (and supports schemas like you mentioned!), but it's not a command line utility, isn't standalone (so would be harder to distribute to XA, for instance), and adds a lot of complexity for features that we don't need right now.

[rgarcia]

Tread carefully here--it looks like there are some strong opinions on both sides about how linters should treat exit codes. E.g. golint: golang/lint#66 https://github.com/golang/lint/search?q=Exit&type=Issues&utf8=%E2%9C%93

[schimmy]

I suppose I am thinking that stdout should usually be easily parseable by machines, and stderr is usually for humans. I'm not 100% tied to this, though, and the current output format is not too hard to regex against if you were trying to incorporate this into a pipeline/workflow.

And you've convinced me on the alternatives :). Definitely being able to direct people to a binary is crucial!

[azylman]

stdout should usually be easily parseable by machines, and stderr is usually for humans

Is that a common convention? I'd always considered it as "stdout is expected output of a program, stderr is for any errors, warnings, or logs that got you there" - basically that the command-line program is a function and the arguments are stdin and the return values are stdout. That's why I have this going to stdout currently, and I like it that way, but I'd be willing to change it if this is against convention.

re: exit codes, I haven't read the golint issues yet, but my initial feeling is to make it exit code 0 when the file is valid (as it currently is), exit code 1 when it's unable to parse the file (as it currently is), and exit code 2 when it was able to parse the file but some lines couldn't lint (currently exit code 0).

[schimmy]

Love the exit code idea. For stdout / stderr, this is not a really strong piece of evidence, but http://unix.stackexchange.com/questions/79315/when-to-use-redirection-to-stderr-in-shell-scripts#comment128689_79321
I particularly like the idea of "Imagine a pipe" when thinking about this stuff...

Again, as long as it's consistent and easily parseable by machines, I'm not too worried. I think I crossed us over into bikeshedding at some point on this one :-/

[schimmy]

this is going to be so critical, love it

[schimmy]

LGTM otherwise!