python: Reinstate lazy imports

[bachorp]

Addresses #19635, #18144
Depends on #21352
Critical commit: 94e39d6

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@cbornet @tomplus @krjakbrjak @fa0311 @multani

[wing328]

thanks for the pr

let me know if you need help updating the samples https://github.com/OpenAPITools/openapi-generator/actions/runs/15953926978/job/44997747683?pr=21486

[bachorp]

@wing328 Done.

[wing328]

thanks. will review and try to get it merged this weekend.

is it correct to say you've used this fix in your production environment and it's working as expected?

[bachorp]

No. I have tested this of course but I'm currently not using openapi-generator in a production setting. I originally wanted this feature to generate usable bindings for the Kubernetes API (the official python client, which is based on a very old version of openapi-generator, is rather poorly maintained) but by now more comprehensive libraries exist. So I don't know whether I will actually need this feature for myself. I have the patch ready nonetheless.

[bachorp]

Maybe some of the other users who reported problems with long import times want to have a look.
@fingon @lawrence-witt @fopinappb

[fopina]

In my case, I experimented very hacky lazy imports but turned into hell dealing with LazyObject so I went with fopina/defectdojo-api-generated#21

Validate_call being the heaviest thing done during import time, I just removed all of them and living happily ever since!

[wing328]

@bachorp thanks for sharing more with us

in this case, i'll let the Python Technical Committee decides whether to accept this enhancement or not.

@cbornet @tomplus @krjakbrjak @fa0311 @multani

[multani]

I'm happy to take a look, but can we clean up the change first? It touches it seems all the generators, although only the Python generator is (should be) changed.

[wing328]

Agreed with @multani

@bachorp Can you please update this one or file a new one with just the changes related to the Python client generator?

[bachorp]

This patch in it's current form is based and dependent on #21352, so I would like to discuss that one first. @wing328 you can find me on Slack.

(I thought I had filed this one as a draft, but apparently not, sorry!)

[wing328]

update: #21352 has been merged. thank you for your contribution.

[bachorp]

This PR now has a clean base.

[wing328]

as there's no further question/feedback, i think we should give it a try

thanks for the contribution

[Thommy257]

I don't want to be a buzzkill or step on someone's toes. Still, with that change, you are potentially pushing a dependency with nine GitHub stars and two maintainers into millions of micro-services. I'd reconsider...

[fopina]

One more vote like @Thommy257
If you really want to keep these approach of lazyimports consider bundling the dependency instead, or the required parts as it should be small
Packages like that one are red flags in component analysis / dependency management

[adam-brusselback]

Ah, this is why my new builds broke a few days ago ;).

I'd agree with @Thommy257, using a dependency with so few maintainers / users is a risk that will be flagged by large corporate security teams (thankfully, I don't have to deal with that anymore).

[wing328]

about history of lazy-imports

---

This project has previously been maintained by the One Conversation team of Deutsche Telekom AG. It is based on _LazyModule from HuggingFace and try_import() from the Optuna framework. Many thanks to HuggingFace for huggingface/transformers#12861 (comment) and to Optuna for optuna/optuna#2776 (comment) to publish it as a standalone package 🤗 ♥.

In December 2024 responsibility was transferred to Pascal Bachor.

---

ref: https://github.com/bachorp/lazy-imports?tab=readme-ov-file#history

is it correct to say that the functionality works fine (no issue as a result of using lazy import), just that the github repo has a few "stars" only?

[Thommy257]

about history of lazy-imports

This project has previously been maintained by the One Conversation team of Deutsche Telekom AG. It is based on _LazyModule from HuggingFace and try_import() from the Optuna framework. Many thanks to HuggingFace for huggingface/transformers#12861 (comment) and to Optuna for optuna/optuna#2776 (comment) to publish it as a standalone package 🤗 ♥.

In December 2024 responsibility was transferred to Pascal Bachor.

ref: https://github.com/bachorp/lazy-imports?tab=readme-ov-file#history

is it correct to say that the functionality works fine (no issue as a result of using lazy import), just that the github repo has a few "stars" only?

Thanks for the clarification, @wing328. I appreciate the effort that went into publishing lazy_imports as a standalone package, and I’ll experiment with it in some of my projects.

That said, I’d like to raise a broader concern. The lesson from the XZ Utils backdoor is that introducing small, low-visibility dependencies into widely used software carries real supply-chain risk. A project with a handful of maintainers and limited adoption is inherently harder for the community to scrutinize. If such a dependency is then injected silently into millions of microservices, as is here, the blast radius of a compromise could be vast.

This isn’t about questioning the integrity of the current maintainers; it’s about weighing security risk versus convenience when choosing dependencies. For now, I’ve pinned openapi-generator to a previous version in my pipeline until consensus is reached.

[wing328]

FYI. Just merged #21885 to add a feature flag for lazy imports