google / google/go-containerregistry
Document philosophy and expectations of pkg/registry
- Dominant language
- Go
- Stars
- 4k
- Forks
- 686
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 26
Description
...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`](https://pkg.go.dev/github.com/google/go-containerregistry/pkg/v1?tab=imports))
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 `map`s 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`](https://pkg.go.dev/knative.dev/pkg/depcheck))
@jonjohnsonjr @mattmoor do you agree to these expectations, and am I missing anything?
Contributor guide
Assessment
This issue has not been assessed yet.