Tracking namespace change

[daspecster]

Here's a place we can track updates to the future changing of the gcloud-python namespace.

This change could break things in the future.

---

Sub-projects already partially created:

• google-cloud
• google-cloud-core
• google-cloud-datastore
• google-cloud-storage
• google-cloud-pubsub
• google-cloud-bigquery
• google-cloud-bigtable
• google-cloud-happybase
• google-cloud-logging
• google-cloud-vision
• google-cloud-speech
• google-cloud-language (and the alias google-cloud-natural-language)
• google-cloud-resource-manager
• google-cloud-translate
• google-cloud-dns
• google-cloud-monitoring
• google-cloud-error-reporting

[theacodes]

Is this in reference to changing to google.cloud?

[daspecster]

@jonparrott yup! I wasn't sure if that was finalized or not.

[theacodes]

@jgeewax can confirm, but from what I understand that is the way we want to go.

[daspecster]

We will want to update the User-Agent string as well for this right? Are there any other implications to that? i.e. people have that user-agent allowed in their apps/firewall.

[jgeewax]

Let's leave the useragent string alone -- we would have a whole heap of stuff to fix if we change that....

Otherwise -- yes, we're definitely going forward with google.cloud as the import path

[dhermes]

Using the form I created

• https://pypi.python.org/pypi/google-cloud
• https://pypi.python.org/pypi/google-cloud-datastore
• https://pypi.python.org/pypi/google-cloud-storage
• https://pypi.python.org/pypi/google-cloud-pubsub
• https://pypi.python.org/pypi/google-cloud-bigquery
• https://pypi.python.org/pypi/google-cloud-bigtable
• https://pypi.python.org/pypi/google-cloud-logging

with the gcloudpypi account on PyPI.

[dhermes]

@omaray I held off on grabbing the equivalents for dns, error_reporting, monitoring, resource_manager and translate, but I can do that as well if you like. I'm not sure if underscores are allowed in PyPI package names?

[theacodes]

@dhermes you can use underscores but it's preferable to use - for consistency.

google-cloud-error-reporting reads better than google-cloud-error_reporting, even if the import path is google.cloud.error_reporting.

[dhermes]

Thanks @jonparrott.

@tseaver @jgeewax @omaray, shall we use google-cloud-core for the code shared by all modules sub-packages?

[tseaver]

google-cloud-core SGTM.

[dhermes]

👍 Just created https://pypi.python.org/pypi/google-cloud-core

[dhermes]

Just created https://pypi.python.org/pypi/google-cloud-happybase for #1762

[omaray]

Thanks @dhermes. All sgtm. Not sure if we added speech, vision, and language - but I guess might as well.

[dhermes]

@omaray Just created https://pypi.python.org/pypi/google-cloud-vision and https://pypi.python.org/pypi/google-cloud-speech

Should it be called google-cloud-language or google-cloud-natural-language?

[tseaver]

+1 for google-cloud-natural-language.

[omaray]

So Ruby and Node.js called it google-cloud-language:

Example: https://www.npmjs.com/package/@google-cloud/language

It's shorter indeed.

If it's easy to do, let's hold both! I'll check with the team.

[dhermes]

If it's easy to do, let's hold both! I'll check with the team.

It is easy but that would just be namespace squatting on PyPI; seems like it would be frowned upon. Though on the flipside, non-Google entities squatting on a name with google in it is also probably frowned upon.

---

I've noticed the Googlers keep calling it Language but that seems to be vague for people not already familiar with the API.

[theacodes]

It's fine to have both google-cloud-language and google-cloud-natural-language as long as you publish a metapackage to one that depends on the other.

(fyi, if we do run into a case where there's someone squatting on our name we can get that resolved).

[dhermes]

So @jonparrott as packaging wizard your opinion is that I should grab both (a) and we should publish to both (b)?

[theacodes]

Grab both and publish to one, and publish a metapackage to the other. But only if you feel like it's really necessary. I'd say don't. Just go with google-cloud-natural-language. Typically the metapackage magic is only done to deal with legacy stuff (like we'll eventually have to do with oauth2client and google-auth).

[dhermes]

Cool. Thanks (I love having a packaging authority person to consult with...as an authority). Grabbed https://pypi.python.org/pypi/google-cloud-language and https://pypi.python.org/pypi/google-cloud-natural-language

[dhermes]

@tseaver @omaray (and anyone else who likes to weigh in) are we a go to grab

• google-cloud-dns
• google-cloud-error-reporting
• google-cloud-monitoring
• google-cloud-resource-manager
• google-cloud-translate

i.e. some of these it's unclear if they deserve their own package / are priorities.

@rimey any preference for grabbing google-cloud-monitoring or google-cloud-stackdriver-monitoring or something else (or both, as we did with language / natural-language above)

[tseaver]

I think those are fine. AFAICT, the -stackdriver bit should be a replacement for -cloud if we are going to use it: (the branding seems confused to me).

[dhermes]

@rimey and @omaray can you weigh in as well?

[omaray]

Yeah, so the whole Stackdriver branding can indeed be confusing. I need to get back to you on that one. For the time being, everything will be google-cloud-{api}.

[omaray]

Yes, confirmed. We are sticking with google-cloud-{api}