-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(common): Fixes issue where we couldn't get a backend type #68
fix(common): Fixes issue where we couldn't get a backend type #68
Conversation
This fixes an issue where if you have a single backend type set, you still would get a None backend type. This meant that unless you explicitly specified a type, it would always resolve to OCI as used by the client. This takes a middle ground approach that lets people write less toml. If an explicit type is not specified and only one type of config exists for a registry, then the backend type of that single config will be used instead. For more than one, you must specify a default. Please note that I renamed this from `type` to `default` as that term better expresses the intent of what this config is doing. A user isn't specifying the type of config so much as the default backend config to use here in the (currently) unlikely case you have a registry that talks more than one protocol Signed-off-by: Taylor Thomas <taylor@cosmonic.com>
I'm not sure about this logic change. My intended behavior for resolving backend is:
This PR adds a new case between the first two options:
This means that an implicit "default backend" would override a registry's explicit "preferred protocol", which seems like it could be a problem if a registry wants to switch preferred protocols. |
Could you say more about the problem scenario this is trying to fix? |
This is solving for the code in
Based on how we have the config set up right now, it implies that theoretically, you could have more than one backend type per registry, so the point here was to be able to indicate that there is a preferred backend to use of the choices available. It also assumes that if you have only one item set, you intend for that config to be used for the registry. Let me restate what I think you are saying should be the order here so we can make sure we're on the same page. The order of precedence for which backend config to use should be:
If this is right and we go with the way it currently exists on main with a config that looks like this: [namespace_registries]
test = "localhost:1234"
[registry."localhost:1234".warg]
config_file = "/a/path" When [namespace_registries]
test = "localhost:1234"
[registry."localhost:1234"]
type = "warg"
[registry."localhost:1234".warg]
config_file = "/a/path" That feels redundant if all I have is a single config block for warg and seems like it would be really simple to miss and then have people wonder why their config isn't loading properly. This is why I had it default if there was only a single backend set. I do have a backend config, and it is warg by default since there is only one. This is the key scenario I am trying to fix here The other use case I am less set on. I don't know if there will be registries that support both warg and OCI simultaneously, but if we are going to have multiple backends (which I assumed was the goal because we have the function that iterates over their types), then there should be a way to specify which one is the default. You can see an example of this in the tests I added. We would probably also need a function that lets you fetch while overriding the choice of backend. So, with that said, we have a few options here:
|
b2b0272
to
7752877
Compare
In the examples and test cases, there is |
That is where the warg config file is loaded from. In the test case, it is just a valid path for testing purposes. In a real config file, that would be pointing to a warg config if it was set |
This fixes an issue where if you have a single backend type set, you still would get a None backend type. This meant that unless you explicitly specified a type, it would always resolve to OCI as used by the client.
This takes a middle ground approach that lets people write less toml. If an explicit type is not specified and only one type of config exists for a registry, then the backend type of that single config will be used instead. For more than one, you must specify a default.
Please note that I renamed this from
type
todefault
as that term better expresses the intent of what this config is doing. A user isn't specifying the type of config so much as the default backend config to use here in the (currently) unlikely case you have a registry that talks more than one protocol