python: Add generated svix/internal openapi client

[svix-mman]

This code was generated using python/scripts/generate_openapi.sh. The code here will be replaced by our new codegen.

[svix-jplatte]

Between CI failing, this being a huuuuge directory and there probably not being a meaningful diff to the new stuff, I feel like I'm turning around on this being useful (even though I said "this is what we did for Rust, let's do it again basically 10 minutes ago). @svix-onelson since you're the one who initiated this for Rust in #1598, how do you feel about it?

[svix-mman]

Funny story about failing CI. Usually ruff format --check would ignore the svix/internal directory, but now since I removed it from the .gitignore it will complain about it

[tasn]

Yeah, I don't think adding the API directories is every useful, as we never have a diff against them, just the models are useful.

[svix-mman]

Yeah, I don't think adding the API directories is every useful, as we never have a diff against them, just the models are useful.

I removed the API directory, this is only the models 😰

[svix-onelson]

Between CI failing, this being a huuuuge directory and there probably not being a meaningful diff to the new stuff, I feel like I'm turning around on this being useful (even though I said "this is what we did for Rust, let's do it again basically 10 minutes ago). @svix-onelson since you're the one who initiated this for Rust in #1598, how do you feel about it?

The motivation for the rust lib doing this was two-fold:

• it meant less effort was needed to customize the build for cli
• it also made iterating on the cli a little nicer since you didn't constantly trip up on "ahh, gotta go regen"

If the question is "should we include generated sources for python, or nah?" I really don't have skin in the game. Either way is fine by me, but (after this initial big diff is done) I think it'll be useful to be able to eyeball the output in PRs.

If the question is "should we stop including generated sources across the board?" then naturally Go would be the exception to the rule as it was before, but also we'd have to do some work to generate sources during the dist build environment for cli.

Make sense?

[svix-mman]

Between CI failing, this being a huuuuge directory and there probably not being a meaningful diff to the new stuff, I feel like I'm turning around on this being useful (even though I said "this is what we did for Rust, let's do it again basically 10 minutes ago). @svix-onelson since you're the one who initiated this for Rust in #1598, how do you feel about it?

The motivation for the rust lib doing this was two-fold:

* it meant less effort was needed to customize the build for cli

* it also made iterating on the cli a little nicer since you didn't constantly trip up on "ahh, gotta go regen"

If the question is "should we include generated sources for python, or nah?" I really don't have skin in the game. Either way is fine by me, but (after this initial big diff is done) I think it'll be useful to be able to eyeball the output in PRs.

If the question is "should we stop including generated sources across the board?" then naturally Go would be the exception to the rule as it was before, but also we'd have to do some work to generate sources during the dist build environment for cli.

Make sense?

In my head, I think tracking the generated models in git is fine (as long as the openapi-codegen generates diffs that are as small as possible)
I am asking about adding these files to git for a different reason, I have the new models (generated using the new codegen) ready.

I want to switch the python client to use them, my question is. What would make the review easier?

1. Committing the current codegen first, then replacing the models with models generated by the new codegen
2. Committing the new codegen without any diff

[svix-onelson]

Ah, I see.

Personally, I don't care about the diff between the old models and the new ones. For python at least we've got some limited test coverage. I'd lean on that for this transition to make sure basic things still align as needed between the models, the api calls, and the server's expectations. If there's concern about an area, add a test for it.

[svix-mman]

Ah, I see.

Personally, I don't care about the diff between the old models and the new ones. For python at least we've got some limited test coverage. I'd lean on that for this transition to make sure basic things still align as needed between the models, the api calls, and the server's expectations. If there's concern about an area, add a test for it.

Ok. I am closing this PR. And I will create a different PR that switches to our new models.