[Catalog-sig] implementing PEP 262 as academic work
bob at redivi.com
Thu May 5 16:04:43 CEST 2005
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
>>> 50 libraries and their dependencies in site-package of Python 2.3
>>> 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.
More information about the Catalog-sig