Validation strategy about mapbox-cli-py

[perrygeo]

Per chat w @sgillies:

• Write validation logic in SDK
• Write click callbacks in CLI (which leverage the validation logic in the SDK)
• Simple functions instead of stateful methods (keep it testable)

I'm still stuck on exactly how the implementation is going to look, it could take one of several forms but I'm currently leaning towards:

• mapbox.validate module exposing a bunch of functions with the signature f(val) -> val and raise a ValueError if anything was wrong.
• mapboxcli.validate module with a bunch of wrapper functions that call ^ and reraise click.BadParameter. These would be click callbacks and take the signature f(ctx, param, val) -> val

The validation modules could even handle the geojson feature validation and normalization.

[perrygeo]

@sgillies, I created validation branches in both the sdk and cli. Started off with geocoding, let's review this before I go ahead with the other services:

In the CLI:
957694d

In the SDK:
mapbox/mapbox-sdk-py@b235003

[sgillies]

Agreed that we shouldn't repeat ourselves. How about this (a restatement of our conclusions from yesterday plus some new thoughts):

SDK

• In the SDK we are committed to preventing requests that will fail 💯 because of invalid arguments (image sizes, travel modes, geocoding datasets)
• Let's validate them using functions in a validation module, not with in-line code.
• Raise SDK-specific exceptions that derive from ValueError (or KeyError for, say, travel modes).

CLI

• We're committed 💯 to sparing CLI users from reading tracebacks.
• The CLI takes responsibility for validating: input/output file paths and the few other things that aren't a concern of the SDK
• Otherwise, rely on the SDK, re-raising its errors as you suggest above.
• We could reserve the option to write validiating Click callbacks using methods from the SDK's validation module if we have a future need.

[perrygeo]

👍 I'll work on implementing this soon.

rely on the SDK, re-raising its errors ...
write validiating Click callbacks using methods from the SDK's validation module if we have a future need

I realized that writing click callbacks means testing everything twice (once on arg parsing, once when you run it). I think just catching SDK exceptions is sufficient and DRY (as long as we have a consistent exception to look out for)