-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: A new user-focused API #1086
Comments
I agree that having the OO abstraction in docker-py would be great since that's what likely everyone is doing in their python projects using docker-py. (e.g. this is what I have in sen: common base class and object specific classes for container and image -- hence I would love to contribute some of the code back to this new API) But please, make it backwards compatible. There's so many tools built on top of docker-py already. So I don't see why you would have to |
A prototype here, if anyone's interested: https://github.com/bfirsh/docker-sdk-python |
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
See docker#1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Implemented in #1186! |
See #1086 Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Problem
The current API is a great wrapper around the REST API, but many common tasks that users want to do don't necessarily map directly to REST API calls. For example, simply running a container is a rather convoluted process.
Proposal
I am proposing we add a higher-level API focused on what users want to do. It should be the default, recommended way of using docker-py.
It could look something like this:
See this sketch of a README for a more examples of how it could work. It intentionally starts with a common thing that users want to do which is complex with the current API: running containers.
Backwards compatibility
This is a good excuse for 2.0. ;)
The new API can be built on top of the current lower-level API. The current API can be made available to users in case they want that extra flexibility and to give them a seamless migration path (
client.api.create_container(...)
or something like that).See also
run()
method could work.The text was updated successfully, but these errors were encountered: