Move '_catch_remap_gax_error' to 'core.exceptions'.

[tseaver]

Toward #3175.

This is the first step toward applying a more uniform mapping of GAX error codes to our exception hierarchy. For a narrower, pubsub-only fix for #3175, see #3443.

[dhermes]

@lukesneeringer Are you good with the dependency changes?

[tseaver]

Note that this change will require releasing a new version of google-cloud-core before / with updated API libraries which use the new google.cloud.exceptions._catch_remap_gax_error. It would obsolete #3443 (which is fine by me).

[dhermes]

👍 on the release (I think @lukesneeringer is somewhat anti to the idea of google-cloud-core churn)

[tseaver]

@dhermes was there another new core feature / fix you thought would land soon? Right now, I see three other PRs touching core since the core-0.24.1 release:

• Adding optional switch to capture project ID in from_service_account_json(). #3436 (forward-compatible feature)
• Vision semi-GAPIC #3373 (docs only)
• iam.Policy: return empty set on missing key. #3424 (forward-compatible default change)

[dhermes]

#3436 was what I was talking about. Looks like we've hit 24 hours, so LGTM?

[tseaver]

@dhermes this PR wasn't in the penalty box :). I'm fine to merge today unless @lukesneeringer has issues with us pushing a new core release to support the subsequent API-specific remapping work.

[lukesneeringer]

Is the core change backwards-compatible (from an API surface standpoint), or is it something where every single subpackage has to be updated?

I do not mind churn on core; back-incompat churn where everything has to move along with it makes me nervous.

[tseaver]

@lukesneeringer the API surface changes are backward-compatible (the add a new, non-API helper function), but the dependency changes are maybe problematic (google-gax becomes an unconditional requirement for core).

[lukesneeringer]

That is a smidge concerning. It would mean that APIs based on HTTP only would now require the installation of (but not use of) GRPC.

Would it be possible to only do the mapping if GAX was present, but not require it? (e.g. try / except ImportError)

[tseaver]

That is a smidge concerning. It would mean that APIs based on HTTP only would now require the installation of (but not use of) GRPC.

We already have this for "dual mode" APIs: even on "classic" GAE they install grpc / gax.

Would it be possible to only do the mapping if GAX was present, but not require it? (e.g. try / except ImportError)

We can indeed revert to doing that: this PR actually backs that stuff out.

[theacodes]

I vote with Luke - can we do this in a way that doesn't require gRPC in core (for now)? I would really like to have this so I can move #3617 forward.

[tseaver]

Redoing this on a new branch (recent core changes make me leery of messing up the original one).

[tseaver]

Reworked in #3707.