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
Thanks for the great tool. I have been working with it for a few months in a sort of interesting situation: my product works directly with the Kubernetes API but is based on asyncio. I have been using kubernetes_asyncio for my Kubernetes interactions in the product and then kubetest within my integration test suite.
Things work fine but there are some interesting side-effects -- I have to carry two copies of the Kubernetes libraries around and take care to ensure that both copies are initialized properly in my fixtures.
I'm tempted to fork you and update kubetest to match my asyncio needs, which is probably a weekend project. If there's interesting in getting this work back into the mainline, I'm willing to work a little bit harder on something mergeable.
I haven't done any serious sketching on this yet but my guess is that the trade-off would be a slightly more complex object hierarchy as I'd need to override all the blocking implementations and some impacts on build/packaging/distribution.
In any case, let me know your thoughts as I am ramping up my investment here and will likely be putting some kind of plan in motion soon.
The text was updated successfully, but these errors were encountered:
Sorry for the delay in my response, this sort of got buried in my notifications.
I'm definitely interested in adding asyncio support. It feels like something super useful that is missing here. I know it's probably late considering you were planning on taking this up on a fork soon, but I'd be happy to help where I can.
No worries, thanks for getting back to me. I'll push up my fork and open an exploratory PR in the coming days to see what it looks like and see if we can map out a path to getting something that is mergeable. I'd much rather fold all this stuff back in and have an async ready kubetest rather than taking on the stewardship of a fork.
Thanks for the great tool. I have been working with it for a few months in a sort of interesting situation: my product works directly with the Kubernetes API but is based on asyncio. I have been using kubernetes_asyncio for my Kubernetes interactions in the product and then kubetest within my integration test suite.
Things work fine but there are some interesting side-effects -- I have to carry two copies of the Kubernetes libraries around and take care to ensure that both copies are initialized properly in my fixtures.
I'm tempted to fork you and update kubetest to match my asyncio needs, which is probably a weekend project. If there's interesting in getting this work back into the mainline, I'm willing to work a little bit harder on something mergeable.
I haven't done any serious sketching on this yet but my guess is that the trade-off would be a slightly more complex object hierarchy as I'd need to override all the blocking implementations and some impacts on build/packaging/distribution.
In any case, let me know your thoughts as I am ramping up my investment here and will likely be putting some kind of plan in motion soon.
The text was updated successfully, but these errors were encountered: