Currently, classify only supports rendering a specific class. Do you plan to add support for more of a package/module level approach? If so: I have thoughts (if not: please close and ignore the rest).
What I do for the pretalx docs is to pkgutil.walk_packages a root package. For each module, I pick public names, check if they are actually defined here or just re-exported, classify the class/function, and record aliases. (E.g. something like pretalx.submission.models.submission.Submission always gets imported as pretalx.submission.models.Submission, so documenting the shorter path is less confusing).
The walk itself is fairly simple. The alias-recording is possibly a bit quirky, but I don't think unreasonable (at least for Django apps with split models, it seems pretty standard to me). As a consumer, I need to know both the canonical location for file/line references, and the import path to render (which imo is the highest-level module that re-exports the class via __all__).
There are definitely some complexities / downsides to this: Walking imports all the stuff, so you get arbitrary side effects, or weird failures when a module was not expecting to be imported without an active Django context. Also can just be expensive, an interface would probably want a filter function (maybe not at first, but eventually).
Currently, classify only supports rendering a specific class. Do you plan to add support for more of a package/module level approach? If so: I have thoughts (if not: please close and ignore the rest).
What I do for the pretalx docs is to
pkgutil.walk_packagesa root package. For each module, I pick public names, check if they are actually defined here or just re-exported, classify the class/function, and record aliases. (E.g. something likepretalx.submission.models.submission.Submissionalways gets imported aspretalx.submission.models.Submission, so documenting the shorter path is less confusing).The walk itself is fairly simple. The alias-recording is possibly a bit quirky, but I don't think unreasonable (at least for Django apps with split models, it seems pretty standard to me). As a consumer, I need to know both the canonical location for file/line references, and the import path to render (which imo is the highest-level module that re-exports the class via
__all__).There are definitely some complexities / downsides to this: Walking imports all the stuff, so you get arbitrary side effects, or weird failures when a module was not expecting to be imported without an active Django context. Also can just be expensive, an interface would probably want a filter function (maybe not at first, but eventually).