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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com