1 Answers1

14

The google.cloud.pubsub library is designed to be make it easy to get the best performance out of a Cloud Pub/Sub publisher and subscriber. It has more advanced features such as message batching, asynchronous message delivery, and automatic ack deadline extension for messages not yet acknowledged by a subscriber. The API is different from the underlying Cloud Pub/Sub service API. For example, this library does not expose the pull method directly; messages are instead delivered to a callback passed into the subscriber's open method.

The google.cloud.pubsub_v1 library exposes the underlying API directly. It can be useful in specific cases where this level of control is necessary, e.g., when a synchronous subscriber is required in order to make requests in response to synchronous actions from a downstream dependency.

When possible, it is best to use the google.cloud.pubsub library.

Kamal Aboul-Hosn
  • 15,111
  • 1
  • 34
  • 46
  • Hi, Just to confirm, is this still valid? I did `pip install google-cloud-pubsub` just now and in virtualenv all it seems to create folders /site-packages/google/cloud/`pubsub_v1`/* ... doing `pip install google-cloud-pubsub_v1` returns: > Could not find a version that satisfies the requirement google-cloud-pubsub_v1 ... – Vibhor Jain Aug 27 '18 at 05:56
  • also, it seems the Client Library (`pubsub_v1`) no longer suppose REST API, it only supports gRPC based API any longer... Thanks! – Vibhor Jain Aug 27 '18 at 05:57
  • @VibhorJain The package to install is `google-cloud-pubsub` which uses the name spaces `google` and `google.cloud` and installs to those pubsub_v1 directories as you found. The name of the directory is not important. Google are moving all the client libraries to gRPC, as mentioned https://cloud.google.com/apis/docs/client-libraries-explained "We plan to upgrade as many Cloud Client Libraries as possible to gRPC" and why not? protocol buffers over http/2 is faster. Ideally, don't write your own REST client code, let the client library handle low level details. – Davos Oct 04 '18 at 13:57
  • Looks like _there is no difference_ pubsub appears to be just importing from pubsub_v1 see https://github.com/googleapis/google-cloud-python/blob/master/pubsub/google/cloud/pubsub.py AND https://github.com/googleapis/google-cloud-python/blob/master/pubsub/google/cloud/pubsub_v1/__init__.py i.e. the pubsub SubcriberClient() class IS pubsub_v1.subscriber.client The `pull` method was blacklisted in the pubsub_v1 client and consequently in pubsub client. That method was also re-exposed https://github.com/googleapis/google-cloud-python/commit/416fbee0cad89337120f123cbf680e27d3b32a5c – Davos Oct 04 '18 at 14:32
  • I think this answer is still correct though, because there are some things not exposed, like futures, and it does have some tricky decorators, blacklisting and add method mechanisms to control the interface. It also makes heavy use of `__all__` to control exactly what is imported. – Davos Oct 04 '18 at 14:42
  • @Davos I had posted a question earlier here `https://stackoverflow.com/questions/52659169/is-google-cloud-pubsub-v1-publisherclient-thread-safe ` does it impact the choice between pubsusb vs pubs_v1 ? – Cryptoharf84 Oct 05 '18 at 12:43
  • @Fadi no I think that question's answer is clear. This page explains the difference between the older `google api client libraries` vs the newer `google cloud client libraries`. The names are similar and it is confusing tbh. https://cloud.google.com/apis/docs/client-libraries-explained – Davos Oct 08 '18 at 02:09