Skip to content

RFC: Automatic generation of type stubs - subclassing install? #5078

@mhvk

Description

@mhvk

Short version: what is the recommended way to add a post-build step to automatically add files to an installation that requires the package itself to be (mostly) functional?

Long version: Over at astropy, we use setuptools as our build backend, including for generating compiled code. We would like to add automatically generated type stubs on installation -- these are stubs for runtime generated units that we rather not carry inside our repository. We found (see astropy/astropy#18573) that this was fairly trivially done by subclassing install and editable_wheel, as follows:

class InstallWithStubs(install):
    """Post-installation command for installation mode."""

    def run(self):
        super().run()
        install_stubs(build_lib=self.build_lib, output_dir=self.root)


class EditableInstallWithStubs(editable_wheel):
    """Post-installation command for editable_wheel mode."""

    def run(self):
        super().run()
        install_stubs(build_lib=self.project_dir, output_dir=self.project_dir)

Here, install_stubs runs code in the built repository. What is really nice about the above is that all the __pycache__, etc., are created in the build directory, but nothing beyond the stubs is added to the install root, so that the wheel does not contain any extraneous content. (For the editable wheel, this is not the case, but it also doesn't matter, since one presumably will soon import the package itself there anyway.)

The question now is whether the above is a good approach, or whether there is a better one. I ask in part since some of our maintainers are hesitant about merging the above because they worry it would be very fragile to possible changes in setuptools. My own sense was that for install at least, this would have worked for years already, and while editable_wheels seems more in flux, the above relies on basics that seem unlikely to change.

Anyway, would really appreciate to hear comments about our approach, or suggestions for a better one.

Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions