CLI design principles and strategy

[sgillies]

Replaces mapbox/mapbox-sdk-py#10.

We're developing a simple and easy to use CLI for the mapbox client module both as a service to customers and as a check on the usability of the module.

The CLI should be 99% about arg/opt definition and interoperation with other programs in the shell.

The CLI will have first class support for JSON and GeoJSON.

We'll rely on other programs like sed, awk, jq for finer parsing of responses from APIs at first, absorbing some of this when it makes sense.

[perrygeo]

The biggest yet-to-be-resolved issue with the design of the CLI is: Do we deviate from 1:1 parity with the API to provide higher-level functions?

• For the sake of docs and consistency with the SDK interfaces, we say No
• For the sake of higher level functionality and improved interfaces ( Add mapbox-datasets-update-features with stdin or file input #36, Mapmatching for mutli-feature inputs #37, [wip] high-level dataset api methods #39, Implement an HTTP cache #43, Batch geocode #44, world files for static maps api #46, Handle uploads of existing s3 objects #49 ) we seem to be suggesting Yes

Maybe we need to define what is and what is not within the scope of this module in terms of how far we can deviate from the API-level interface. For instance, the batch geocoding and high-level datasets API implementations are awesome but they could also be broken out as separate tools (even sharing the same "mapbox" namespace through the use of click plugins).

[sgillies]

@perrygeo checking with you on our current strategy:

Yes to higher level functionality. We've already made mapbox-upload more frictionless than the APIs and this command is going to become our main tool. We should reduce friction in other tools when we can.