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 _______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
