[Catalog-sig] implementing PEP 262 as academic work

[Bob Ippolito]

On May 5, 2005, at 8:57 AM, Maurice Ling wrote:

>> Maurice Ling wrote:
>>
>>
>>> Given that (1) there can be multiple versions of Python installed  
>>> in a
>>> system, (2) each version maintains their own site-packages  
>>> directory and
>>> (3) if C modules are installed, they are not compatible with other
>>> versions of Python... Imagine a system administrator who had  
>>> installed
>>> 50 libraries and their dependencies in site-package of Python 2.3  
>>> and
>>> now has to do it for Python 2.4, can we make his life better?
>>
>> I'd like to point out that this is a task that the "native" package
>> format can solve. For example, in Debian, when I use Debian packages
>> to install the 50 libraries, the current Debian Python policy manages
>> to update all the libraries from Python 2.3 to Python 2.4, when
>> the "official" Debian Python version becomes 2.4.
>>
> From your point of view, I do agree that you do not need more  
> intervention from disutils. In fact, if the package maintainers so  
> desire, you do not even need disutils at all. So the question here  
> is, is PEP 262 really needed at all? I can see that Martin or  
> anyone using Debian may not need it. However, at where I am (MacOSX  
> with Fink), I need it.
>

Since Fink uses the same software that Debian does, why shouldn't the  
same upgrade pathway work?  What did they screw up?  They've screwed  
up other things, so I don't use or trust Fink, but I'm just curious...

When using Mac OS X without the help of a "trusted third party" like  
Darwinports or Fink, or when using Windows (where there isn't such an  
option), there is a most definitely a use case for PEP 262.   
Additionally, the Python world generally moves a hell of a lot faster  
than the Debian world, so there's probably some reasons to have PEP  
262 even in such an "ideal" world where dependencies (almost) "just  
work" without Python's help.

-bob