get rid of interactivity

[notslang]

At first I liked it, but the more I think about it I keep going back to Doug McIlroy's advice:

Don't insist on interactive input.

I'll reevaluate this later, but interactivity should be cleanly separated from the core.

[jescalan]

Eh, it's very limited in this library, only for convenience. It just writes the details to your shipfile. If you don't want to see if you can put the details there in the first place. Unless it's proving to be a setback to the library in some way, I see no reason to remove what is really just a convenience feature.

[kylemac]

we will keep interactivity

[notslang]

Are the repercussions of that able to be discussed, or should I just follow without questioning? Not trying to sound mean or anything (that's a legitimate question, not a rhetorical one). I'm used to operating on consensus for these kind of projects, so I'm not sure which one.

[kylemac]

I was hasty in not providing my reasoning when I closed this issue, sorry:

• I was concerned it's openness was causing inaction. the issue has been open for 17 days with little progress going on around it
• We already have interactivity built into v0.0.2, so the repercussions are much smaller than if we changed it

you'll find we'll do our best to debate openly to try to come to the best solutions, but those debates can't come at the expense of shipping. occasionally I, or another empowered member of carrot will have to make a call so we can move forward. beyond that if you're looking for consensus, it appears we have 2:1 for interactivity.

let's readdress the issue once we've got a more complete product.

[notslang]

• Ok, hastiness is understandable.
• Yeah, I should've replied to this sooner - I was still considering how the interface should work at the time
• The repercussions that I was referring to are:
  • right now the automatic updating of the config file causes the github deploy to fail whenever the interactivity is used (because of the gh-deployer's uncommitted changes warning). This could be fixed, but it's a pain and I'd rather focus on getting ship shipped without this convenience feature. We could of course add an interactive "make a config file" command later, but it's not a high priority feature.
  • Having interactivity makes it much harder for other scripts to use the CLI interface, which is part of the reason why the Unix philosophy says it should be avoided.
  • Interactivity is a pain to test (which is why we don't have tests for it right now)

And that's good - I assumed that you openly debate from what I saw in roots, but I wanted to make sure.

Lol, true - but consensus isn't about siding with the majority (even though that is the quickest way). It's a painful (yet effective) process of testing/evaluating solutions, addressing/dissecting people's concerns, and determining weights given to priorities - until a decision can be reached objectively. If people withhold concerns it does speed up the process, but the validity of the decision can be impacted by the lack of those peoples' input.

...Or at least, that's the way that I learned it.

[jescalan]

For the github issue, just commit the changes as "update shif.conf" before deploying. Other scripts should not be using the cli interface, they should be using the actual js API. And it is indeed a pain to test, but that's something we need to work on for a few libraries, not just this one.

In addition, as mentioned earlier, this is a convenience feature, not a critical piece of functionality. Since it seems like you are really hung up on it let's just leave it unimplemented for now and focus on other more important things. Like the actual deployers.