Remove engine-api dependency from docker/docker/daemon about engine-api HOT 6 CLOSED

@tonistiigi I like the idea for the long term 👍. The first step is then to backport the daemon specific one in docker/docker, removing the dependency and then decide wether or not we want to vendor some or just re-define them.

from engine-api.

Creating a cycled dependency doesn't sound any better to me, tbh.

from engine-api.

@calavera docker/docker "daemon" struct and docker/engine-api struct could be completely independent, but yeah, we shouldn't create a cycled dependency.

from engine-api.

@calavera There is no cycled dependency. Client depends on engine-api and does not depend on daemon. Daemon does not depend on engine-api. Engine-api depends on types from daemon subpackages(optional but I think cleaner).

from engine-api.

Seems like keeping 2 repos so that so tightly linked is a lot of work/pain for very little benefit - as we've seen.

If the client were a totally independent project and changes didn't propagate in both directions, and had its own life cycle, then perhaps this would be a good option. But in reality they're very linked and I don't see the benefit of trying to force a split. As we've seen, many times, we end up with PRs in two repos and that causes pain and extra work - so let's just stop that.

IMO, we should move it all back to one repo with very clear pkg lines/boundaries, so that people can vendor at the appropriate spot (APIs, types, etc...) but allows for a single PR to introduce changes from CLI->API->types->Engine (and tests at CLI,integration) all in one shot - its so much easier to review/test that way.

from engine-api.

closed by moby/moby#26349

from engine-api.