registry/client/repository.go implements a client-side version of ManifestService. However, the ManifestService interface doesn't map well to the client-side functionality, and as a result there are some unintuitive aspects of this implementation:

• Get can operate on either a digest or a tag, contrary to the documentation in ManifestService which says "Get retrieves the manifest specified by the given digest". To retrieve a tag, it's necessary to use a functional option which causes the dgst argument to be ignored.
• Put needs to be passed a tag, otherwise it fails to build a URL with the error mux: variable "" doesn't match, expected "^[\\w][\\w.-]{0,127}|[a-zA-Z0-9-_+.]+:[a-fA-F0-9]+$". However, the interface doesn't include a tag argument, so this is passed in through a mandatory functional argument (which is specific to the client implementation).

My initial conclusion was that the client side version is sufficiently different from the generic ManifestService that it shouldn't try to satisfy the interface. Instead, it should expose its own member functions that make sense (GetDigest, GetTag, Put with a tag argument). I tried to make this change, but found that repository.Manifests must return distribution.ManifestService, otherwise *repository doesn't satisfy the distribution.Repository interface. So it's not easy to unravel the web of interfaces. I'm not sure how to proceed, but would really like to find a way clean up the awkwardness in the client-side manifest functions.