[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