vendor-packages directory

[Terry Reedy]

"Rich Burridge" <Rich.Burridge at Sun.COM> wrote in message 
news:4330293A.7030503 at sun.com...
> 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