[Python-Dev] Re: Stability and change (original) (raw)
Stephen J. Turnbull stephen@xemacs.org
09 Apr 2002 19:59:25 +0900
- Previous message: [Python-Dev] Re: Stability and change
- Next message: [Python-Dev] Re: Stability and change
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> For most mortals, the XEmacs package manager simply *sucks*.
GvR> Maybe that is because it's broken out of the box and you have
GvR> to find the right webpage that tells you how to manually fix
GvR> some things. But it still sucks.
"BAW" == Barry A Warsaw <barry@zope.com> writes:
BAW> I agree totally, but that's a quality of implementation
BAW> problem. Once it works, it's (almost) great.
I wish. There are real problems waiting to bite us, besides the gratuitous menu changes and implementation sillinesses, such as its dependence on EFS.
The main one that is Python-planning-relevant is that you guys have standard libraries nested several deep all over the place, no? We have about five packages that other packages consider "a lot closer to core than I am": APEL (used by many), EFS (by the package manager itself), semantic/eieio (by JDE), and widget.el (used by just about everything via the Customize facility). JDE, the Java Development Environment, is one of our big problem children because it insists on being distributed with its own versions of semantic and eieio. Fortunately, nothing else much uses them. EFS (Extended File System) is well-done and well-maintained, but unfortunately by design depends on external FTP implementations, and every few months Red Hat or SuSE "does something" to FTP (kerberize, whatever) and EFS loses on that platform---as does our package manager.
APEL is "A Portable Emacs Library", and what it does is smooth over backwards compatibility issues. Unfortunately, it does it in ways that (a) tend to introduce forward compatibility issues and (b) not really visible to debuggers. This leads to embarrassments where A Leading Developer says on Usenet that XEmacs supports such-and-so API from GNU Emacs 21, and then discovers that it ain't so, it's actually subtly different code from APEL---only the docstrings are the same.
The widgets are pretty stable, but they're only loosely coupled with anything besides Custom.
In other words, the main reason our package system has been so successful is that we simply don't have to worry about the issues this thread is about. But in a few cases where we do, we tend to lose. So be cautious. I won't say our experience proves it can't work; I'd actually rather say the glass is half-full, and I think that you guys can fill it better than we have so far. But it won't come "for free", there's more conceptual work to do than just "do it better than XEmacs."
And Andrew Kuchling mentions Debian apt, well, that's the direction a number of the library developers are heading in terms of wishlists.
For all that, it's been a roaring success with our users.
Fortunately-for-them-the-BDFL-is-not-our-BDFL-ly y'rs,
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.
- Previous message: [Python-Dev] Re: Stability and change
- Next message: [Python-Dev] Re: Stability and change
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]