[Python-Dev] New relative import issue

Phillip J. Eby pje at telecommunity.com
Fri Sep 22 06:10:45 CEST 2006


At 08:44 PM 9/21/2006 -0700, Josiah Carlson wrote:
>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.

As far as I can tell, you're ignoring that per-user must *also* be 
per-version, and per-application.  Each application or runtime environment 
needs its own private set of information like this.

Next, putting the installation data inside a database instead of 
per-installation-unit files presents problems of its own.  While some 
system packaging tools allow install/uninstall scripts to run, they are 
often frowned upon, and can be unintentionally bypassed.

These are just a few of the issues that come to mind.  Realistically 
speaking, .pth files are currently the most effective mechanism we have, 
and there actually isn't much that can be done to improve upon them.

What's more needed are better mechanisms for creating and managing Python 
"environments" (to use a term coined by Ian Bicking and Jim Fulton over on 
the distutils-sig), which are individual contexts in which Python 
applications run.  Some current tools in development by Ian and Jim include:

      http://cheeseshop.python.org/pypi/workingenv.py/
      http://cheeseshop.python.org/pypi/zc.buildout/

I don't know that much about either, but I do know that for zc.buildout, 
Jim's goal was to be able to install Python scripts with pre-baked sys.path 
based on package dependencies from setuptools, and as far as I know, he 
achieved it.

Anyway, system-wide and per-user environment information isn't nearly 
sufficient to address the issues that people have when developing and 
deploying multiple applications on a server, or even using multiple 
applications on a client installation (e.g. somebody using both the 
Enthought Python IDE and Chandler on the same machine).  These relatively 
simple use cases rapidly demonstrate the inadequacy of system-wide or 
per-user configuration of what packages are available.



More information about the Python-Dev mailing list