Please add settings.json and/or a README

[litch]

I was trying to run these tests, and set this up on CI, but was unable to:

[2015-10-18T20:46:24.562-04:00] Settings::DataSource::File ERROR: Settings cannot be read from settings/event_store_client_http.json. The file doesn't exist.

[sbellware]

I'm not sure I'm following... The settings file is there in the source. It should be picked up when the tests are run.

[litch]

Please document how to invoke the tests

Sent from my iPhone

On Oct 19, 2015, at 8:53 AM, Scott Bellware notifications@github.com wrote:

I'm not sure I'm following... The settings file is there in the source. It should be picked up when the tests are run.

—
Reply to this email directly or view it on GitHub.

[sbellware]

How about if we establish a convention where a library has a test.sh file that runs the tests, and consequently demonstrates how they're run?

[litch]

Sure. Sounds good. As long as it is documented somewhere. Are you resistant to using README's for that purpose in general? I have sensed a lot of resistance from you about using README's. We are writing these things for humans, so should communicate human to human about how these work (even if that consuming human is our future selves)

Sent from my iPhone

On Oct 19, 2015, at 9:21 AM, Scott Bellware notifications@github.com wrote:

How about if we establish a convention where a library has a test.sh file that runs the tests, and consequently demonstrates how they're run?

—
Reply to this email directly or view it on GitHub.

[sbellware]

No, no resistance at all. Just that we have a lot of READMEs to write, and I don't want to just "ad hoc" them into existence through rapid response actions. I can see a quick path to another kind of mess if we don't put at least a little thought into the structure of READMEs.

[litch]

Right. Maybe we need to treat these libraries with a little more respect. I know that you want as little resistance as possible to people generating libraries as their whims desire, but each library has a nonzero maintenance cost. We are spending so much time maintaining this set of libraries now, and yet essentially none of them are usable in the case that 1) the original author wants to use it again and so re-digs through the source code to understand it, 2) someone else wants to dig through the original author's source code, or 3) someone wants to coerce the original author into explaining it to them - in which case the original author reads through source code to reacquaint themselves with the project.

Making consumption of libraries dependent on reading someone else's source code is just naked geek hostility of the highest order. Let's please stop inflicting that violence on our coworkers.

[sbellware]

Yep, I agree completely. It's really a bit of effort that hasn't bubbled up to the highest (pre-empting other work) level of priority yet. That's pretty much what it comes down to in the end: the time to make a document that does the job of explaining how to make a library work (and to not just do it to put a plausible-deniability checkmark next to the work item).