[Python-Dev] New relative import issue

[Armin Rigo]

Hi Guido,

On Thu, Sep 21, 2006 at 07:22:04AM -0700, Guido van Rossum wrote:
> sys.path exists to stitch together the toplevel module/package
> namespace from diverse sources.
> 
> Import hooks and sys.path hackery exist so that module/package sources
> don't have to be restricted to the filesystem (as well as to allow
> unbridled experimentation by those so inclined :-).

This doesn't match my experience, which is that sys.path hackery is
required in any project that is larger than one directory, but is not
itself a library.  The basic assumption is that I don't want to put
whole applications in 'site-packages' or in my $PYTHONPATH; I would like
them to work in a self-contained, zero-installation way, much like they
do if they are built from several modules in a single directory.

For example, consider an application with the following structure:

   myapp/
      main.py
      a/
         __init__.py
         b.py
         test_b.py
      c/
         __init__.py

This theoretical example shows main.py (the main entry point) at the
root of the package directories - it is the only place where it can be
if it needs to import the packages a and c.  The module a.b can import
c, too (and this is not bad design - think about c as a package
regrouping utilities that make sense for the whole application).  But
then the testing script test_b.py cannot import the whole application
any more.  Imports of a or c will fail, and even a relative import of b
will crash when b tries to import c.  The only way I can think of is to
insert the root directory in sys.path from within test_b.py, and then
use absolute imports.

(For example, to support this way of organizing applications, the 'py'
lib provides a call py.magic.autopath() that can be dropped at the start
of test_b.py.  It hacks sys.path by guessing the "real" root according
to how many levels of __init__.py there are...)


A bientot,

Armin.