-
Notifications
You must be signed in to change notification settings - Fork 2
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
Remove zds-client usage #88
Comments
@damm89 - you're the only party I know making use of zgw-consumers and this will very likely cause some breaking changes for you. I intend to document the breakage in the changelog and include some pointers to what the implementation used to be, so you can move over the code to your own project(s)/libraries. Does that work for you? |
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
get_catalogi and get_informatieobjecttypen appear to not be used in any of our projects. Users who do make use of this are advised to copy the code from 0.31.0 to their own projects or libraries.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
Downstream projects/libraries should implement this functionality themselves, as it turns out it is not as common as initially anticipated.
Merged
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
We're dropping the zds_client dependency, which removes our requirement to handle OpenAPI specifications, thus we can/should also remove our cache handling for schemas.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
Removed because it's unused in our own projects. If you do make use of this, you can instead use the equivalent code: ```py client = Service.get_client(some_resource_url) ```
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
Better typing support and still emits the runtime warning.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
Added a check for the legacy module that zds-client is installed, since the dependency is now moved into an optional group. TODO: vendor the ClientAuth in zgw-consumers directly instead of relying on zds-client.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
These are tightly coupled to zds-client. Rather than changing their signature, we opt to deprecate them and provide the alternatives to use.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
This allows us to drop the dependency on zds-client entirely
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
This allows us to drop the dependency on zds-client entirely
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
…model Environments/projects that don't use zds-client anymore already do not need to be burdened with these fields. This approach makes it safe to not break on run-time and allows opt-in for project that know what they're doing.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
…model Environments/projects that don't use zds-client anymore already do not need to be burdened with these fields. This approach makes it safe to not break on run-time and allows opt-in for project that know what they're doing.
sergei-maertens
added a commit
that referenced
this issue
Mar 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are some internal bits and pieces that use zds-client under the hood which need to be removed or updated before we can drop support for zds-client alltogether (we have alternative bindings for ape-pie already).
Most notably, this will impact some of the admin and ZGW API's integrations. Currently I'm leaning towards removing this functionality, as we barely use it ourselves anymore and we want to move zgw-consumers more in the direction of a "service configuration" library rather than having tight integration with the ZGW APIs (a rename will happen at some point to hammer this point home).
Possibly we will split of some integration code into another library, but this is not a guarantee.
The text was updated successfully, but these errors were encountered: