What went before
Modulegraph is a library for creating a dependency graph between python modules and is the engine used by py2app to determine which python code to include in the generated application bundle.
The library was written a long time ago and was incrementally updated for new Python features. Along the way I’ve also tried to add unittests, but there we’re never terribly good.
The way forward
At the end of 2018 I started working on a complete rewrite of the modulegraph library, leading to the release of modulegraph 2.0a1 on PyPI today.
Modulegraph2 is a modern Python 3.6 or later code base, designed for easier unittesting and with type annotations. This combined with a helpfull sprinkling of flake8 extensions should make it a lot easier to maintain the library going forward.
It has been a delight to work on this, even if this rewrite took a lot longer than expected. Importlib takes care of a lot of the low-level gruntwork, allowing me to focus on building a usable dependency graph.
Using Python 3.6 and ignoring Python 2 is a much nicer development experience than trying to support older versions. This in the end allows for cleaner code, and faster development. I was also pleasantly surprised by mypy: it took some time to get used to using the tool, but in the end it helped in finding and fixing bugs early in the development cycle. And that’s on a pretty small code base (3.5K lines of python code, including whitespace, comments and docstrings).
The codebase is functionally complete, but has seen light usage at best. The code passes the full testsuite on macOS (with Python 3.6 and 3.7), but hasn’t been tested on other platforms yet. The current version number reflects that the current status: It is a major change from modulegraph, but needs more testing before I’m truly convinced it is ready for a stable release.
The command-line API can create HTML and Graphviz reports of the dependency graph, but these are fairly crude at the moment (although not worse than those created by modulegraph). It should be fairly easy to create more useful reports in the future.
Plans for the future
My plan for the near future is to create an (experimental) branch of py2app that uses modulegraph2 instead of modulegraph, to further validate the design and functionality of the modulegraph2 library.
In a longer timeframe I’d like to do a simular rewrite for py2app: rewrite the code base in a testable way for Python 3.6 and later, and also redesign the py2app interface (moving away from a setuptools command as the main interface).
Modulegraph2 can be downloaded through PyPII (“pip install modulegraph2==2.0a1”), with documentation on readthedocs