google / google/go-containerregistry

Document philosophy and expectations of pkg/registry

Open
#1,166 9 comments 0 reactions 1 assignee Claimed by @jonjohnsonjr View on GitHub
dependencies lifecycle/frozen
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.