"Rich Burridge" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I work in the Accessibility Program Office at Sun Microsystems. I'm > part of a team that is using Python to create a screen reader called > Orca, that'll help blind people (and people with low vision) have > access to the GNOME desktop for Solaris and Linux. > http://cvs.gnome.org/viewcvs/*checkout*/orca/docs/doc-set/orca.html
Very nice. I am old enough to know I might need such a program some day. > Orca in turn uses several packages that interface between Python and the > various "native" libraries in the GNOME desktop: > > * pyorbit - Python bindings for ORBit2 > * pygtk - GTK+ Python bindings > * gnome-python - Python bindings for various GNOME libraries > > We will be presenting our project in front of one of the archirectural > review committees within Sun soon, in order to try to get this software > in a future release of the Solaris operating system. It's Open Sources, > so other Linux vendors will also be able to pick it up (if they so > desire), > to include with their software distributions. > > We've been given a heads-up on the following problem. > > Until now we've been using "/usr/lib/python2.4/site-packages" as the > directory to install the various Python files that these packages use. My impression is that this is exactly the intended place for general-use support packages. > We have been told that this directory is inappropriate for vendor > supplied > packages, As you of course know, 'appropriateness' in in the eye of the beholder. >From Python's viewpoint, there is no difference that I know of between 'vender' supplied packages and 'sharer' supplied packages. So this looks to me like arbitrary whim. Is there any rationale that I am missing. > Now we could easily create a "/usr/lib/python2.4/vendor-packages" [... snip] If there are other package writers who don't use site-packages, perhaps they will read this and share their experiences and solutions. > What I'd like to see is a future release of Python automatically checking > for this directory and appending it to the list of directories that it'll > search. Python has done fine, it seems, without this. What benefit would I and hundreds of thousands of other people get from having such a directory on our machines? > Here's a patch to do this: > > --- Python-2.4.1/Lib/site.py Mon Sep 19 12:37:00 PDT 2005 > +++ Python-2.4.1-new/Lib/site.py Mon Sep 19 12:37:00 PDT 2005 > @@ -182,7 +182,11 @@ > "lib", > "python" + sys.version[:3], > "site-packages"), > - os.path.join(prefix, "lib", "site-python")] > + os.path.join(prefix, "lib", "site-python"), > + os.path.join(prefix, > + "lib", > + "python" + sys.version[:3], > + "vendor-packages")] > else: > sitedirs = [prefix, os.path.join(prefix, "lib", > "site-packages")] > if sys.platform == 'darwin': Patches generally belong on one of the Python sourceforge trackers. If you decide to pursue this, this could go either under Patches or maybe RFEs. > Is this something that would be considered for a future Python release? My guess would be no, better to persuade whoever to let you use Python as intended. But I don't really know. The decision would be made either by GvR, who will not see this here, or one of the top developers, who might or might not. But I am pretty sure you would need a better rationale than 'my superior is hung up on the directory name' or 'Perl has two package directories'. Support from other package venders would definitely be a plus. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
