-
Notifications
You must be signed in to change notification settings - Fork 9
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
improvement(dev-ex): compatible/identical types should be aliased and reused where possible #38
Comments
@the-wondersmith @kflynn and myself all sync'd about this recently. This would be a large boon to the ergonomics of using the library. There were a few options on the table, but we all agreed doing this at the CRD level in the upstream repository might be the best one because it has the additional potential to help other languages and clients in the future. /cc @aryan9600 as this also relates to our statuses work in #37 |
(Don't worry, this has not fallen off my radar I have a reminder set for it) I was hoping to hear from @aryan9600 (ping!) but I think the general idea of the Gateway API project providing CRD information for client generation seems generally helpful and reasonable to ask for at some level. Basically any proposal should follow the GEP process, and in this case I think it would be fair to start a discussion referencing both this issue and #39 and reasoning, and then we can continue discussion there as well as bring it up at the community meeting. Once it's had some time for discussion, we'll see if we can gather any other allies and then ultimately find out who are going to be the champion(s) driving it forward to completion. Please feel free to start that discussion! oh and @astoycos and @clux, you might find this interesting as well. |
@the-wondersmith checking in? |
No worries! Let's discuss there for a bit and see what people think 🫡 |
I think we should try to bring this topic up in a Gateway API community meeting to try to spark more interest. If no further interest can be sparked, then it might be a situation where we just ask (the Gateway API community) "is anyone opposed to us creating a GEP for this?" and see where we can go from there. |
Agreed. When / where is that? |
https://gateway-api.sigs.k8s.io/contributing/#meetings |
(Don't we now alternate 3PM PST and 8AM PST every other week?) |
Ooop yep, Flynn is right 👍 |
So we haven't gotten any feedback in upstream, so I guess it's really up to us how motivated we are, and what specific way we're motivated to do this. My thoughts at this point is that this would be ultimately more beneficial to add in |
Apologies for the delay, the notification got buried 😖. I couldn't agree more - What's a good starting point for us on that path? |
@clux I think at this point we should ask your opinion on the matter: tldr; when generating code from CRDs there can be duplicated types which are identical (e.g. re-used sub-types in the source API). We have been considering how we could influence (more details above and in the links) |
This would be a great ergonomic improvement in general to have. My bet here would be on some extra key/info in the schema that can serves as some kind of namespaced NB1: It's a shame that we can't set NB2: The thing we* recently started doing; matching for well-known apimachinery type structs is so heavy handed that it's not really fit for this purpose / exposable (without injecting arbitrary code somewhere). |
It would dramatically improve the crate's usability if instead of defining discrete types for every nested object within a CRD, compatible/identical types were defined once and automatically reused.
For example, the
HeaderMatch
type is identical betweenGRPCRoute
andHTTPRoute
resources, and do not require discrete handling when writing code to handle them. Another good example would be the way thatHTTPRouteFilter
s are a superset ofGRPCRouteFilter
s and can therefore also be handled by the same code without special consideration (i.e. any code that handles allHTTPRouteFilter
types inherently also handles allGRPCRouteFilter
types).As the crate currently is, a dev would have to write such code with the
newtype
pattern or work a bit of black magic to skirt the orphan rule. A much more ergonomic solution would be if types that were actually the same to simply have exported aliases where you'd expect them to be ([example]) or for types where the compatible type is effectively a subset toimpl From<SubsetType> for SupersetType
([example]).In the case of aliased types, I'd imagine we'd want something like:
and in the case of compatible types:
The text was updated successfully, but these errors were encountered: