You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently this repo builds two tools: the
registry
CLI 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:registry
tool to a new repo (registry-tool
?) and most of the CLI support code inpkg
would go with it.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 thepkg
directory. But it's not immediately clear where the protos should reside. I think we want to avoid havingregistry-server
depend onregistry
, because it would inherit theregistry
dependencies, so this suggests that the protos and generated proto and grpc support code should be in the newregistry-server
repo. But thegapic
and all other client-related code would remain inregistry
and 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 theregistry
repo.The text was updated successfully, but these errors were encountered: