I borked the repo name in the kokoro config 😆. Will re-run shortly.

This PR removes the handwritten layer since the costs of maintaining that handwritten layer seem greater than the benefits

I believe the long term plan is for our team to eventually update and maintain the handwritten libraries for this. It may be worthwhile keeping the existing API surface around instead of forcing customers to switch back and forth

That being said, I don't think Trace is going to be on our radar for a while. And I'm not familiar with the library, so I'd have to do some digging to see if the existing hand-written part is even worth keeping. It looks pretty light weight. I'd probably prefer to go fully auto-generated for now and re-assess later (if the customer impact isn't too high). What do you think @simonz130?

I think it's uncommon for folks to interact with this library directly. It looks like the docs push folks to interact with the Trace API via OpenCensus or OpenTelemetry.

https://cloud.google.com/trace/docs/client-libraries

For your application to submit traces to Cloud Trace, it must be instrumented. You can instrument your code by using the Google client libraries. However, it's recommended that you use OpenTelemetry or OpenCensus to instrument your application. These are open source tracing packages. OpenTelemetry is actively in development and is the preferred package.

The OpenCensus StackDriver Trace Exporter declares google-cloud-trace as a dependency. https://github.com/census-instrumentation/opencensus-python/blob/862885af8081dc3ede50d1df4a28e4400c22e8f8/contrib/opencensus-ext-stackdriver/setup.py#L43

We should trim the manual layer from this library and make a major release as a result. We should focus on steering folks to use OT exporter instead of this library directly.

Thanks @simonz130 @daniel-sanche! I'll cut a release on Monday.

Thanks for getting this done. I've pinged the Cloud Trace team in case they want to follow up, but it looks great!