feat: Change from_dict from staticmethod to classmethod BNCH-17564

[forest-benchling]

This allows from_dict to be inherited and overridden by subclasses. I couldn't think of any scenarios where this would be a breaking change, unless someone was relying on incorrect subclass inheritance.

The only relevant changes are model.pyi and pyproject.toml. The rest of the files are from regenerating the e2e test.

Test Plan

poetry run mypy ~/openapi-python-client/end_to_end_tests/golden-record-custom/custom_e2e/models/

[forest-benchling]

@packyg I could use some help understanding how all this works--

Should I be submitting a PR against the upstream original repo at the same time?

Are the e2e tests sufficient, or are there unit tests I should be updating?

[packyg]

Yeah, you should upstream this. It might be better to only upstreaming this and then we pick up the changes when we rebase next.

To do that I'd start from the main branch of upstream and cherry pick your change, then make an upstream PR with that (noting that it fixes openapi-generators#215). The upstream maintainer is pretty responsive so would probably be pretty quick to incorporate the change. We could then work with @bowenwr to pull it in when he gets back.

---

The e2e tests are going to be the right way to check this. There's 2 different codegens that should happen - it looks like you did both of them, but I just want to make sure you did it with poetry run task re

Also, you can run poetry run task check to do all of the static code checks (isort/black/mypy) and pytest.

[packyg]

We don't own this version number - even if we weren't upstreaming this change, we should leave it so we don't have conflicts later when we rebase or fork

Suggested change

	version = "0.7.4"
	version = "0.7.3"

[bowenwr]

Aside from Packy's existing comments, this looks great. I agree, I'd love to get it upstreamed so we can pull it in. Excellent work @forest-benchling !

[forest-benchling]

To do that I'd start from the main branch of upstream and cherry pick your change, then make an upstream PR with that (noting that it fixes triaxtec#215). The upstream maintainer is pretty responsive so would probably be pretty quick to incorporate the change. We could then work with @bowenwr to pull it in when he gets back.

@packyg I'm still a bit confused to do this. It looks like I don't have permission to push to the upstream triaxtec repo. Do we have a branch in our fork that is identical to main in the upstream? If so, wondering if I can make my change off that branch, and then do a cross-fork PR?

[packyg]

@packyg I'm still a bit confused to do this. It looks like I don't have permission to push to the upstream triaxtec repo. Do we have a branch in our fork that is identical to main in the upstream?

@forest-benchling No we don't, but you could just do it in our repo, based on the upstream main.

git remote add -m main upstream git@github.com:triaxtec/openapi-python-client.git
git fetch --all
git checkout -b my-branch upstream/main
git cherry-pick ...

If so, wondering if I can make my change off that branch, and then do a cross-fork PR?

Yes, that's what you'll have to do - create the branch in our repo, but make a PR against the upstream by changing the merge base to triaxtec/openapi-python-client@main. You could even do that with this PR, though it would have extra commits in it from our allOf support, etc. which is why I suggested starting afresh and cherry picking only the relevant chagnes.

An example of one of the PRs I made from our repo to the upstream can be found here: openapi-generators#268 (though that PR wasn't ultimately used b/c the maintainer wanted to tweak it a bit while we were off for winter)