docker / engine-api

DEPRECATED: Please see https://github.com/docker/docker/tree/master/client
Apache License 2.0
264 stars 163 forks source link

[Proposal] Moving the client package to docker/docker #379

Closed icecrime closed 8 years ago

icecrime commented 8 years ago

Problem statement

The docker/engine-api repository was created to create a true decoupling between Engine internals and its public interface. A lot of valuable and solid refactoring came out of it, but today, most maintainers are complaining about the operational trade-offs it incurs.

Proposal

The content of this repository will be moved back as a sub-package of docker/docker. We absolutely want to preserve the architectural boundary, but we want to remove the repository boundary which is too cumbersome.

Under that scenario, what should we do with the docker/engine-api repository?

  1. Abandon it in its current version, and encourage people to now import github.com/docker/docker/api/client/ (exact path TBD).
  2. Have it contain the latest stable version of the client package extracted from github.com/docker/docker/api/client/ (exact path TBD).

I'm curious about your opinions @vdemeester @ibuildthecloud.

duglin commented 8 years ago

I'd prefer option 1 since with golang people can just vendor it "as is" and not have to worry about whether "master" of docker is, or is not, master on the APIs. People will just know they're always at the same level. Plus, a tag of docker will automatically cover both areas. We don't need to worry about tagging 2 repos.

lowenna commented 8 years ago

I would concur with @duglin. Absolutely though, trying to bring these back together in some manner that remains architecturally clean is goodness and makes life (for me at least - others might disagree :innocent: ) significantly easier.

vdemeester commented 8 years ago

Although I like engine-api a lot (it's smaller to get than docker/docker when vendoring :stuck_out_tongue_closed_eyes:), I think it has to be done at some point :sweat_smile:. The code in engine-api is to tied to docker/docker anyway so…

If we do it, I also prefer option 1 ; given also that we do something like #358 too 👼…

bfirsh commented 8 years ago

Agreed with option (1). For #358 we can just create a completely new repo with a better name.

jessfraz commented 8 years ago

FWIW 1,646 projects on github import the types package here alone... do you have a plan for informing people?

crosbymichael commented 8 years ago

@jfrazelle we are not going to delete this or anything. Existing imports will continue to work.

I'm sure we can add this change in the next release notes, etc so that people can get the updated client in the next release.

jessfraz commented 8 years ago

maybe a warning on init or something though? idk if that is more pain though for people

crosbymichael commented 8 years ago

Ya, i thought about that but if that happens to me I usually freak out because some package is logging messages in my program.

I'll update the readme in this repo as a start and trying to think of a way to notify the people.