...or just move it to internal/registry and document that the expectation is that users should fork it if they want to use it.

Moving conversation out of #1158 into a separate issue.

Since its inception, pkg/registry has been intended mainly to support integration tests -- e.g., to ensure that pkg/v1/remote can actually push and pull against a relatively simple, lightweight, conformant registry implementation. Since then, because it's in a public package that people can depend on, external projects have come to depend on it, mainly also to support integration tests (I think).

pkg/registry used to have zero dependencies aside from stdlib, but in #798 it gained a dependency on other ggcr packages (pkg/v1, also itself very lightweight, only depending on stdlib and pkg/types)

Aside from tests, it's also useful as a basis for a simple lightweight registry implementation, and #1158 aims to make its storage mechanism pluggable, presumably to support persistent disk storage (or something else, I have no idea and don't care). I think we're all on the same page that this is useful, and pkg/registry should be extensible. The expectation that it remain free of extraneous dependencies has never really been documented though, and we should do that. Perhaps in a pkg/registry/README.md.

I would propose staking out roughly these expectations:

• pkg/registry should not depend on anything besides stdlib and go-containerregistry's own packages (I think this is non-controversial).
• storage (and maybe someday auth?) should be pluggable via interfaces, with in-memory storage using maps as the default. If other implementations are provided by ggcr, these must also only depend on stdlib and ggcr packages.
• we may consider adding tests to enforce these expectations (e.g., depcheck)

@jonjohnsonjr @mattmoor do you agree to these expectations, and am I missing anything?