Currently this repo builds two tools: the registry CLI and the registry-server. To allow these to be separately versioned and to minimize their dependencies, let's consider splitting this into two repos. Two possible options are:
move the registry tool to a new repo (registry-tool?) and most of the CLI support code in pkg would go with it.
move the registry-server to a new repo (registry-server?)
In either case, we should maintain history by making the copy a fork of the main repo and then pruning the two repos to be nonoverlapping.
Option 2 (create a registry-server repo) seems less disruptive to downstream tools that import the pkg directory. But it's not immediately clear where the protos should reside. I think we want to avoid having registry-server depend on registry, because it would inherit the registry dependencies, so this suggests that the protos and generated proto and grpc support code should be in the new registry-server repo. But the gapic and all other client-related code would remain in registry and reference their dependencies from registry-server. Note that there's also proto-based generated code in pkg/application, but since none of these types are used by the server, this code can probably remain in the registry repo.
Currently this repo builds two tools: the
registryCLI and theregistry-server. To allow these to be separately versioned and to minimize their dependencies, let's consider splitting this into two repos. Two possible options are:registrytool to a new repo (registry-tool?) and most of the CLI support code inpkgwould go with it.registry-serverto a new repo (registry-server?)In either case, we should maintain history by making the copy a fork of the main repo and then pruning the two repos to be nonoverlapping.
Option 2 (create a
registry-serverrepo) seems less disruptive to downstream tools that import thepkgdirectory. But it's not immediately clear where the protos should reside. I think we want to avoid havingregistry-serverdepend onregistry, because it would inherit theregistrydependencies, so this suggests that the protos and generated proto and grpc support code should be in the newregistry-serverrepo. But thegapicand all other client-related code would remain inregistryand reference their dependencies fromregistry-server. Note that there's also proto-based generated code in pkg/application, but since none of these types are used by the server, this code can probably remain in theregistryrepo.