Initial commit of Resource Manager API

[jgeewax]

Looking for feedback first. This is short on tests (hence the "don't merge" label), but follows the client pattern @dhermes used for PubSub.

API overview is here: https://cloud.google.com/resource-manager/reference/rest

[jgeewax]

@dhermes : Looks like I'm having lint errors. Errors I'm seeing that I don't know exactly what to do:

Module gcloud.resource_manager.client

• W:126,28: Redefining built-in 'filter' (redefined-builtin)
• C:195, 4: Invalid argument name "id" (invalid-name)
• W:195,22: Redefining built-in 'id' (redefined-builtin)
• C:221, 4: Invalid argument name "id" (invalid-name)
• W:221,26: Redefining built-in 'id' (redefined-builtin)

Using id isn't cool?

Module gcloud.resource_manager.connection

• W: 21, 0: String statement has no effect (pointless-string-statement)
• W: 28, 4: String statement has no effect (pointless-string-statement)
• W: 31, 4: String statement has no effect (pointless-string-statement)
• W: 34, 4: String statement has no effect (pointless-string-statement)

These are all docstrings...

Module gcloud.resource_manager.project

• C: 63, 8: Invalid attribute name "id" (invalid-name)
• W: 61,31: Redefining built-in 'id' (redefined-builtin)
• W: 86, 8: Access to a protected member _set_properties_from_api_repr of a client class (protected-access)
• W:252,34: Redefining built-in 'reload' (redefined-builtin)
• W:286,36: Redefining built-in 'reload' (redefined-builtin)

Using id and reload isn't cool? And I can't call the protected method when creating the object?

[dhermes]

Linter Comments

---

Using id and reload (and filter) isn't cool with the linter as variable names because they end up in locals, and will accidentally override builtins.

RE: "String statement has no effect (pointless-string-statement)" How old is your version of pylint? Do a tox --recreate -e lint.

RE: "Access to a protected member _set_properties_from_api_repr of a client class (protected-access)" The linter only wants you to access protected methods on self, so it's a no-no in a class method.

[jgeewax]

Using id and reload (and filter) isn't cool with the linter as variable names because they end up in locals, and will accidentally override builtins.

OK, so I have to change those variables then, yes?

RE: "String statement has no effect (pointless-string-statement)" How old is your version of pylint? Do a tox --recreate -e lint.

I'll upgrade and give another go.

RE: "Access to a protected member _set_properties_from_api_repr of a client class (protected-access)" The linter only wants you to access protected methods on self, so it's a no-no in a class method.

Recommendations?

[dhermes]

Yes use different variable names. People usually just add some more context, e.g. filter_foo or they just cop out and append an underscore filter_.

Let me know what happens after upgrade (I suppose if it happened on Travis, it's legit, since Travis always uses latest.)

Recommendations about protected method, just make it public.

[jgeewax]

But reload is OK as a method name, right? (https://github.com/GoogleCloudPlatform/gcloud-python/blob/master/gcloud/pubsub/subscription.py#L139)

[dhermes]

@jgeewax Correct reload is OK as a method name (per the linter) because it doesn't conflict with any local or global namespaces (since it is a method).

[jgeewax]

OK @dhermes : All set :)

[dhermes]

Starting to review now. It's strange that the coveralls check never ran.

[dhermes]

OK I finished reading the code from beginning to end. We shall continue discussion in the comments 👍

[dhermes]

(Not trying to be a wet blanket) After thinking about it for a little bit, I'd rather we move the reload_data feature out of this PR and discuss it on it's own after the basic functionality is in.

[dhermes]

FYI @jgeewax I am porting this over today.

[jgeewax]

Awesome - thanks @dhermes.

On Mon, Aug 24, 2015 at 6:37 PM, Danny Hermes [email protected]
wrote:

FYI @jgeewax https://github.com/jgeewax I am porting this over today.

—
Reply to this email directly or view it on GitHub
#933 (comment)
.