Should we make Project a real thing in gcloud? Particular for gcloud.storage?

[jgeewax]

Our discussions in the past have said that we want Connection to remain stateless and really just handle sending data over the wire as well as authentication.

However, if you think about it, now that we're planning to push the "transformation" (from Python objects -> JSON) down to Buckets, Blobs, and ACLs, the connection object isn't really just doing transport, it's also representing a connection to a specific project.

Do you guys think it's worthwhile to make "project" a first-class citizen so that it makes more sense to do things like project.get_all_buckets() ?

This leads to a question of "what is the relationship with connections and projects? We could have a one-to-one between them (where what you really do is instantiate a project and under the hood it instantiates a connection which handles auth, etc). Or we could have a singleton connection that all the projects use with their own set of credentials...?

I am +0 on doing this kind of thing, and only just thought of it now given we need a "clean" place to put get_all_buckets() -- so feel free to close out as "stfu, that's dumb".

/cc @dhermes

[tseaver]

The only bit of storage.Connection that relies directly on self.project is build_api_url, but that method is the core of everything else the connection does. I can't see us usefully breaking out a Project object: I don't think there would be anything left of 'Connection'.

[jgeewax]

OK - so what I'm hearing is: there really isn't a need. Is that right?

[dhermes]

Ditto what @tseaver says

[tseaver]

Sounds like consensus to me.