z3c.dependencychecker: setup.py requirements up to date¶

Tags: python, zope

If you import from it, you must mention it as a dependency in your setup.py. That’s sane advice.

Problem: when do you notice it? When do you grep your files for import? Some imports work just fine as another dependency depended on the thing you’re importing. Still, it is safer to also include that dependency if you use it directly: if the dependencies get refactored (for instance the large-scale cleanup in zope’s libraries), the indirect dependency might not help you out anymore.

Solution: z3c.dependencychecker. Install it and run “dependencychecker” inside your python project. It will report on:

• Unused imports: pyflakes is another tool that does this (and that also reports on missing variables inside the files).

• Missing (test) requirements: imports without a corresponding requirement in the setup.py. There might be false alarms, but at least you’ve got a (hopefully short) list of items to check.

  Watch out for packages that have a different name than how they’re imported. For instance a requirement on pydns which is used as import DNS in your code: pydns and DNS lead to separate “missing requirements: DNS” and “unneeded requirements: pydns” warnings.

• Unneeded (test) requirements: requirements in your setup.py that aren’t imported anywhere in your code. You might need them because not everything needs to be imported. It at least gives you a much smaller list to check by hand.

• Requirements that should be test-only: if something is only imported in a test file, it shouldn’t be in the generic defaults. So you get a separate list of requirements that should be moved from the regular to the test requirements. (Since version 0.3).

It is not perfect yet. from zope import interface is treated as a requirement for zope instead of the actual zope.interface package. (Note: support for ‘from’ added in version 0.4!) And before you remove something, please grep around a bit. Doctests also aren’t checked yet. (Note: support for doctests added in version 0.5!)

It is already helping me in cleaning up grok’s dependencies. Grok uses the zope tool kit’s libraries and they’ve seen some major dependency refactoring. Grok 1.1 is supposed to reap the fruits of that. But for that to happen, grok’s own requirements need to be right, of course. So I’m now going through grok and grokcore.* :-)