[Distutils] desirability of multiple, divergent Python instances

[Daniel Krech]

On Apr 14, 2008, at 12:59 AM, Stephen Waterbury wrote:
> Ben Finney wrote:
>> Greg Ewing <greg.ewing at canterbury.ac.nz> writes:
>>
>>> 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 can't see how this is a good idea. I've seen it mentioned multiple
>> times in this thread, but without justification.
>>
>> It's my position that the Python instance one uses for development
>> should diverge as little as possible from the default system  
>> instance.
>> Otherwise one is actively pursuing a recipe for dependency failures
>> when one eventually deploys the result.
>
>> Yes, there should be a way to deploy the code one is actively
>> developing and testing to some location that will not affect the rest
>> of the operation of the system. That is a far cry from asking that
>> there should be multiple, divergent Python instances on the system.
>>
>> The further step of saying that the operating system should not use
>> the same Python instance as a "user" on the system (and note that the
>> line between those is far from clear), but instead should use some
>> Python instance that behaves differently from every other use of
>> Python on the system, seems like an even worse proposition, for the
>> above reasons.
>>
>> Help me understand, please.
>
> Have you read my proposal?  It's in the message posted by me to this
> thread at 12:31 PM today.
>
> My main motivation in proposing it is to give the user complete  
> control
> over the Python environment that is in their path -- which is not  
> easy to
> do on Debian/Ubuntu at the moment -- by giving the Python utilities  
> and
> packages that OS-related functions depend on a completely insular  
> Python
> environment that the OS can manage however it sees fit.  In my view,  
> both
> as a developer and a user, but especially as a developer, it would  
> make
> life easier.

This seems related to the use case I was going after in 'autoinstall'.  
Which is to move the control of the Python environment to the  
application. This way each application can have its own insular Python  
environment.

A first baby step in that direction:

     http://pypi.python.org/pypi/autoinstall/0.1a2

Currently it only supports binding dotted packages names to URLs  
(relative or absolute) that point to zip importable versions of the  
package. But I've been using it some and it's been making my life  
easier indeed.

Curious what people think of a per application approach? The use case  
seems to be mentioned a fair bit in the various threads.