OO API?

[fragmede]

Hello,

The API currently returns a dict from many calls where it seems, perhaps naively, an object would be more useful. I'm aiming to add some OO notions to the API exposed by docker-py, but not before consulting people here.

For example, Client.create_container returns a dict, and usage looks like:

client = Client()
cont = client.create_container(**info)
if 'Id' in cont:
    client.start(cont['Id'])

with needing both client and cont for the 'start' call. Whereas if create_container returned a hypothetical Container object, the container run code then look like:

client = Client()
cont = client.create_container(**info)
cont.start()

There's a branch called 'objects' that looks like the very beginnings of such an approach, but it hasn't been touched in 3 years, and current master shows no sign of incorporating any OO notions for the API, outside of docker.Client.

Why that approach was dropped? I'd like to look at adding some objects to the API, but not if there were unforeseen issues with that. If there are issues, it would be preferable to have them written down and documented here. (There are various ways to approach supporting legacy code, but if an OO api is fundamentally incisompatible, for whatever reason, then discussing support of legacy code seems premature.)

I was unable to find any docs or issues relating to this particular architectural decision, though I did come across #417 and #538, which aren't this specific question.

[shin-]

It's been considered. A more recent branch that implements a similar behavior is efficiency ( https://github.com/docker/docker-py/commits/efficiency ), but it's not yet at a point where I'm satisfied with it in terms of code quality and robustness, and it's stayed fairly low priority compared to other tasks.

The reality is, not everyone needs or even wants an OO approach, so if any efforts are made in that direction, they should keep the experience intact for people using the library as it is currently.

[bfirsh]

#1186. 🎉