tefra
Public API
Hello, and thanks as always for the fantastic package.
I have a question regarding what should be considered part of the public API. I found that 24.2 broke my code because SchemaTransformer was no longer available in xsdata.codegen.transformer. It looks like the documentation PR https://github.com/tefra/xsdata/pull/928 renamed it to ResourceTransformer (it's a lovely PR otherwise :) )
Since there are very few "private" modules and classes in xsdata (in the conventional sense of being prefixed by an underscore), and quite a large API surface area... is there a heuristic that we can use to determine whether something might change without deprecation?
thanks!
In general I am trying to maintain compatibility with the binding modules, I never thought people would try to extend the transformer. I see you are using it to disable some handlers and mine some docs not generated in simple types. Maybe for things like that I would introduce some entrypoints like hooks.
In my mind adding a custom codewriter and a class type would be enough for people to extend xsdata.
I am sorry for any inconvenience, refactoring the docs a lot of stuff made no sense at all 🤦 and to be honest I am gonna rename more things down the road, if you could share what parts
no worries, I'm probably touching/importing more of xsdata than the average user.
I agree that my subclassed Transformer could probably be removed with a couple additions. And yes, you've got it right, in my case, I could use a hook to modify xsdata.models.xsd.Attribute.display_help, and a hook to modify ClassContainer.processors. I remove RenameDuplicateAttributes (vaguely related to https://github.com/tefra/xsdata/pull/806)
If you're open to these hooks, I could have a look at implementing it for you and submitting a PR. It's low urgency of course, I'm probably one of the few who need it
@tlambert03 which handlers are you disabling?
Some of them will become mandatory, otherwise the class validator that runs in the end will fail
I remove RenameDuplicateAttributes here:
https://github.com/tlambert03/ome-types/blob/35d28911ad820f3b75ee392fb88918f747204808/src/ome_autogen/_transformer.py#L74-L78
and i do that so that I can inject my own enum names here: https://github.com/tlambert03/ome-types/blob/35d28911ad820f3b75ee392fb88918f747204808/src/ome_autogen/_generator.py#L272-L276
(the details of why i had to do it that way are a little hazy to me at this point... i think it was related to #806, and it's possible that there is a better fix for what I ran into... if in the future you have to make a change that breaks my current workaround, that's just fine, I'll figure out a new way... maybe a more "proper" way :)
you are safe then... please let's open new issues/pr with some suggestions about possible hooks.
sounds good 👍 I'll open PRs with any proposals going forward and we can discuss more concretely