Gael Varoquaux wrote: 
On Mon, Apr 14, 2008 at 01:30:14PM +1200, Greg Ewing wrote:
  
Gael Varoquaux wrote:
    
a second Python
needs to be installed on top of the system Python to add modules to it.
      

  
Maybe the system should come with two pythons installed,
one for use by the system and the other for users to add
things to. Or at least be set up so that it appears that
way -- they might share files under the hood.
    

I am quite wary about these proposals, as well as the one environment per
application ones.

In my experience, it is a fairly standard practice across all platforms to install independent application environments for any large, complex applications that come with a vendor support agreement.   Admittedly, that isn't alot of Python applications, especially of the kind you're referring to where users are expected to add, remove, and intermix modules.  However, that doesn't mean there aren't any Python apps that do fit the bill -- in fact, Enthought does alot of that.   We want our apps to work even if the sysadmin upgrades the system libraries, Python, or what have you, or if the user installs multiple applications that have competing library requirements.

What you propose resembles very much to what MacOSX does, and MacOSX
seems just so broken for Python. I don't use it, but I see on the
different scientific-Python-related mailing lists how users have
difficulties with MacOSX, and I have heard many people complain about
this "feature".

As a per-application environment, I think it is bad, because it limits
reuse. As I see things, applications should be able to have access to all
the Python modules installed, to be able to use them, if they need. I get
definitely see applications having more feature if some modules are
installed (eg. Sphinx, which does syntax highlighting if pygments is
installed).

I think this discussion is really going on because Python does not have
good library-versioning support. What it needs is to get this, and not to
get complete isolation, apart for some system-critical tasks, and only
for these. AFAIK this is one of the problems setuptools is trying to
solve. Not everybody is happy with the technical solution setuptools has
come up, this only means it has to be improved.

IMO, this sort of multi-version thing only works if *everything* in the stack participates fully.  I think the reason more things don't do this is because of the maintenance load it puts on developers / release managers to bump and synchronize versions apporpriately.


-- Dave