NOTE: This is alpha software, the API is not stable,
do not use this in production, as upgrades may break everything.

import_resources is an experimental fork of pkg_resources, aimed at addressing some of the usability issues that arise when the entry-point related integrity checks conflict with the multi-versioning support.

This isn't currently a high priority project - it's something I plan to tinker with as time is available.

The advantage offered by changing the name is freedom to experiment with the API without needing to worry about backwards compatibility. In particular, the aim is to support:

1. (at least) two stage initialisation for multi-version support (e.g. running a wsgi app under gunicorn, getting projects to play nice with sphinx and pylint).

  1. Eliminating any global side effects of importing the module

3. Separating the sys.path manipulation (i.e. multi-version support) from the sys.path scanning (i.e. entry point support)

This is mostly driven by my experience with relying on the pkg_resources multi-version support in Beaker (

  • gunicorn breaks, since the script wrapper imports pkg_resources,

implicitly activating the wrong version of CherryPy, so the bkr import fails due to a version conflict

  • sphinx autodoc breaks, for the same reason
  • pylint breaks, again for the same reason

In all 3 cases, we have to use a convoluted python -c invocation to bypass the script wrapper's early import of pkg_resources, and the resulting implicit activation of the default versions of everything before the bkr specific code has a chance to declare its own application specific dependencies.