Using docker/distribution instead of docker/docker?

[glestaris]

Hello,

containers/image imports docker/docker for the reference package which is used for types of for reference parsing [1]. docker/docker is a quite big repository and would prefer to avoid having it as a dependency in GrootFS [2], which consumes containers/image.

Would it be possible to use docker/distribution instead for the reference types/parsing? Additionally, the Docker transport package seems to be doing all the requests to a Docker registry [3]. Could this behavior be delegated to docker/distribution?

Thanks!

[1]

image/docker/docker_transport.go

Line 47 in 0c795ea

ref, err := reference.ParseNamed(strings.TrimPrefix(refString, "//"))

[2] https://github.com/cloudfoundry/grootfs
[3]

image/docker/docker_image_src.go

Line 71 in 0c795ea

res, err := s.c.makeRequest("GET", url, headers, nil)

[glestaris]

If you think with can replace docker/docker with docker/distribution dependency, we would be happy to make PRs that implement the required changes. WDYT?

[runcom]

just a quick reply w/o actually looking at the whole code I think this is reasonable if it can be done, ping @mtrmac

[mtrmac]

Hello,

containers/image imports docker/docker for the reference package which is used for types of for reference parsing. docker/docker is a quite big repository and would prefer to avoid having it as a dependency in GrootFS, which consumes containers/image.

Would it be possible to use docker/distribution instead for the reference types/parsing?

Not trivially; we use the canonicalization facilities from docker/distribution (FullName and the effect of normalize).

Of course this could be copy&pasted into this repo, at the risk of divergence.
But we explicitly went the other way in #32 , though there is little discussion about rationale in there.

Additionally, the Docker transport package seems to be doing all the requests to a Docker registry [3]. Could this behavior be delegated to docker/distribution?

That would probably be possible, I have no idea about the cost/benefit. To the extent the current code “works” (admittedly it’s not nearly as polished as docker/distribution) I wasn’t personally motivated to change it, though that wouldn’t prevent accepting a PR of course.

---

In abstract the question is whether to import from external dependencies to avoid behavior divergence and effort duplication, or whether to copy&paste / reimplement to avoid breakage on API or behavior changes, and possibly to make it easier to change things. I don’t think we have a consistent answer to this trade-off, and the suggestion to avoid pulling in docker/reference but to depend on docker/distribution also shows that making a simple rule is difficult.

My personal preference would generally be towards using external dependencies and not duplicating the work, OTOH I haven’t been around docker/docker long enough to know how painful it can be.

As a first impression, “docker/docker is a big git repo” seems a fairly weak reason to duplicate the docker/distribution code; though it is unfortunate how the github.com/docker/docker/image/v1 reference in there pulls in much more than we really need.

@runcom , #32 was your PR originally. Any thoughts on that?

[runcom]

@runcom , #32 was your PR originally. Any thoughts on that?

as you perfectly explained - even if docker is a big git repo, it is moving fast and we could lose bits (which could be bug fixes). So the rationale behind that PR was to avoid moving away from docker as it's not an issue to depend on them (unless of course you take into account the size of that repo)

[glestaris]

Thanks @mtrmac and @runcom. Copying and pasting small chunks of code is usually better than a dependency, but I understand that in this case docker/docker/reference provides us with canonicalization behaviour that we don't want to regress against.

On using docker/distribution for the interaction with the registry, I am happy to know that you would consider a PR. The cost is certainly high and possibly higher than what we would be willing to pay for what we want to achieve currently. I will open a new issue soon to become more specific on that.

Thanks!