tracing: using package with import errors is unreasoanable and defeats the purpose of adding instrumentation if a feature should be programmed without even dependencies

[odeke-em]

python-spanner/google/cloud/spanner_v1/_opentelemetry_tracing.py

Lines 20 to 32 in e15e84f

	from google.cloud.spanner_v1 import gapic_version
	try:
	from opentelemetry import trace
	from opentelemetry.trace.status import Status, StatusCode
	from opentelemetry.semconv.attributes.otel_attributes import (
	OTEL_SCOPE_NAME,
	OTEL_SCOPE_VERSION,
	)
	HAS_OPENTELEMETRY_INSTALLED = True
	except ImportError:
	HAS_OPENTELEMETRY_INSTALLED = False

to me is a very unreasonable condition because we say that these libraries are traced meanwhile on just a single failed import, we work around this and then return None for spans. Why not fail loudly when dependencies are not correctly installed? This feels more like a kludge and customers can falsely use the package thinking they are exporting spans: no other language instrumentations work like this: if a customer doesn't want OpenTelemetry, let them disable it but that should not leak into our code, because OpenTelemetry-Python will provide a NoopSpan. Ensuring that the imports work correctly should be a pre-requisite.

Kindly cc-ing @harshachinta @sakthivelmanii @surbhigarg92 @alkatrivedi

[harshachinta]

This was done because the Python client library supports Python 3.7, which lacks OpenTelemetry support. To prevent code from breaking in Python 3.7, we had to handle import errors accordingly