On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote: > On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote: > > If it's not supposed to be a public module, it shouldn't be in a public > > directory, and then there's no reason to provide more packages than just the > > application package. > FWIW, this is not the common attitude in the Python community; people > think it's a good idea to store application-specific modules and > extensions in the site directory, even if there's no API/ABI stability. > For example, I've had several requests for Quod Libet to install its > entire private module hierarchy there. You'll find that several programs > in Debian, such as gnome-menus, do this already. > Personally I think that's very stupid, and leads to 1) a false sense of > security about the stability of such APIs, and 2) a lax attitude towards > API compatibility in general in Python (since so many "public modules" > break all the time). Yes; putting libraries in public directories that aren't going to support a stable API/API for the lifetime of a release (be it Debian or python) is simply namespace pollution. It's unfortunate that every language community has to grow into an understanding of this the hard way. > If Debian is going to buck the trend here (and I think it should, and > thankfully does for many programs) a lot of packages are buggy. Well, I think "a lot of packages are buggy" is a pretty accurate assessment whether Debian adopts a blanket policy on this or not... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature