Skip to content

Stub generation

Michi Hostettler requested to merge stub-generation into master

Going forward to 2021, this is finally a first version to integrate stub generation directly into cmmnbuild_dep_manager at resolve time. It is optional, and can be disabled via an argument to the resolve() method (e.g. for release distributions).

To not fully open the box of Pandora, and to speed things up a little, this does not "blindly" generate stubs for all java packages. Instead, python modules that have registered with cmmnbuild_dep_manager can "request" stubs for certain Java packages by providing a list of strings as __stubgen__packages__. See https://gitlab.cern.ch/scripting-tools/pjlsa/-/blob/cmmnbuild-dep-mgr-stubs/pjlsa/__init__.py for how this could look like. Like for the JAR resolution, cmmnbuild_dep_manager will build the union of all requested java packages, and then fire up stubgenj to do the actual generation. The generated stubs are placed into the dist dir of cmmnbuild_dep_manager (which must be writable, but we are hopefully all using virtualenv now?).

If anything goes wrong during stub generation, the exception is caught a warning level message is logged. In this respect, I would consider stubs as "nice to have" extra information, not as something essential that should fail the resolution process if it goes wrong.

Note that for customized JPype collections, the stub generation is not yet optimal due to https://github.com/jpype-project/jpype/issues/915, but still better than nothing I presume.

Merge request reports