[Python-Dev] New relative import issue

[Josiah Carlson]

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> Guido van Rossum wrote:
> 
> > Eek? If there are two third-party top-level packages A and B, by
> > different third parties, and A depends on B, how should A find B if
> > not via sys.path or something that is sufficiently equivalent as to
> > have the same problems?
> 
> Some kind of configuration mechanism is needed, but
> I don't see why it can't be a static, declarative one
> rather than computed at run time.

I could be missing something, or be completely off-topic, but why not
both, or really a mechanism to define:
1. Installation time package location (register package X in the package
registry at path Y and persist across Python sessions).
2. Runtime package location (package X is in path Y, do not persist
across Python sessions).

With 1 and 2, we remove the need for .pth files, all packages to be
installed into Lib/site-packages, and sys.path manipulation.  You want
access to package X?
    packages.register('X', '~/mypackages/X')
    packages.register('X', '~/mypackages/X', persist=True)
    packages.register('X', '~/mypackages/X', systemwide=True)


This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5).  There can be a system-wide database that all users use as
a base, with a user-defined package registry (per user) where the
system-wide packages can be augmented.

With a little work, it could even be possible to define importers during
registration (filesystem, zip, database, etc.) or include a tracing
mechanism for py2exe/distutils/py2app/cx_freeze/etc. (optionally writing
to a simplified database-like file for distribution so that SQLite
doesn't need to be shipped).


 - Josiah