Add support for multiple interface versions #297
Conversation
github-actions
bot
added
enhancement
github-actions
bot
added
the
code-gen
…rantami-serverapi-openapi into feat/multiple-versions
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
A couple of requested changes left as comments.
Also, something that's more of a template request, but it's inspired by what I see here. In the spirit of our closed source package, could we find some way of alerting the user to the fact that they're using a dev version, or that the latest version was built from a non-released version of MI? When we only had a single version of the interface it was obvious, and you'd just refer to the package version for the stability, but now it's not so clear cut. An idea:
- Update the codegen template to write some constant to the generated code as to whether it's the dev version or not.
- Add logic to the top level
__init__.pyfor each submodule that does something broadly like "if this is the dev version and it's a pre-release build, raise a warning on import"
That way we generate warnings if anyone ever uses a pre-release interface, but we don't raise a warning for anything else, even if it's in a pre-release wheel. We will however have to remember to flip that flag in the code when we copy it across.
Maybe there's a way of having it figure out if it's the latest build automatically, but that might be tricky to do cleanly without a whole load of extra imports.
| @@ -38,11 +38,13 @@ jobs: | |||
| cache: maven | |||
|
|
|||
| - name: "Clean library folder" | |||
| run: find . ! -name 'poetry.lock' -type f -exec rm -f {} + | |||
| run: find . ! -name 'poetry.lock' -path './src' -prune -o -type f -exec rm -f {} + | |||
There was a problem hiding this comment.
Could we just use maven clean to do all of this and remove this step entirely? It's a bit odd having two different ways of doing different parts of the same job.
| @@ -32,7 +32,7 @@ | |||
| Generated by: https://github.com/swagger-api/swagger-codegen.git | |||
| """ | |||
|
|
|||
| import ansys.grantami.serverapi_openapi.models as models | |||
| import ansys.grantami.serverapi_openapi.v252.models as models | |||
There was a problem hiding this comment.
Is there a way we can run these tests on multiple versions of the generated code? Or I suppose, on the latest dev version? I can see us forgetting to change this and ending up with tests running against an old version of the package.
Ideally we'd import everything, and maybe xfail any specific versions where we know the tests don't work? Or import and run over a subset of all versions for each test if we know the behavior under test was only supported by a certain version. They should be open-ended though, to always pull in new tests, assuming we never break any existing functionality.
This PR adds an initial sketch of how we might support multiple versions in the same package. This should allow us, if we want, to support older versions of Granta MI from the same version of the package.
The changes are faily minimal, I pulled the python code from the released versions of 2.0, 3.0, and 4.0, and put them into namespace folders. The pom.xml was updated to build in the v252 folder, and that value is now a separate variable. I added a custom clean step to clean out that directory, and updated the clean library folder script to skip the src directory entirely.
The version of the client template was updated to allow multiple py.typed files to exist, otherwise the code generator was perfectly happy to export what we needed.