This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add a vendor-packages directory for system-supplied modules
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ajaksu2, alexis, barry, bkabrda, brian-cameron-oracle, carljm, dhduvall, doko, eric.araujo, jbeck, loewis, ncoghlan, piotr.dobrogost, richard, richburridge, rkuska, tarek, terry.reedy, trent
Priority: normal Keywords: patch

Created on 2005-09-22 15:12 by richburridge, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit
Python-01-vendor-packages.diff richburridge, 2005-09-22 15:12 Patch to add "vendor-packages" to the Python search list for packages.
vps.diff dhduvall, 2011-05-19 16:54
Messages (17)
msg48758 - (view) Author: Rich Burridge (richburridge) Date: 2005-09-22 15:12
Python needs a .../python2.x.y/vendor-packages directory
for vendor supplied Python files.


for the full reasoning behind this request.

I also approached Guido w.r.t. this. Here's his reply.

Subject: Re: Python vendor-packages directory in a
future Python release?
Date: Tue, 20 Sep 2005 19:48:40 -0700
From: Guido van Rossum <guido at>
Reply-To: Guido van Rossum <guido at>
To: Rich Burridge <Rich.Burridge at Sun.COM>
References: <>

I think that's a reasonable request. (In the mean time,
I think that
using site-packages is fine as an interim solution.)

I suggest that you use the SourceForge patch manager
for the Python
project to upload your patch, and then post to
python-dev. You may be
asked to review 5 other patches in order to have
someone look at your
favorite patch.

msg48759 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2005-09-23 23:49
Logged In: YES 

The reason for this patch given in the referred-to post is:

"We have been told that this directory is inappropriate for vendor 
supplied packages, just as "site_perl" is inappropriate for Perl. 
With Perl, vendor supplied packages go under "vendor_perl". "

where 'this directory' is site-packages, which works fine.

The python-dev thread subequent to this posting starts with
A subsequent post
clarifies that 'vendor supplied packages' here means packages 
installed by the system/OS vendor.

Disconnected (in the pipermail archives) pieces of the thread 
start here
and here

This last suggests that this proposal is on hold while a .pth 
solution is explored.

msg48760 - (view) Author: Rich Burridge (richburridge) Date: 2005-09-29 14:47
Logged In: YES 

A good alternative solution to this problem was given on the
mailing list. See:

The architectural commitee have approved this solution, so
I'm closing
this bug as "Invalid". If there'd been a "Withdrawn"
resolution, I'd have
closed it that way instead. Perhaps that's what Deleted is
supposed to
do. Feel free to tweak if I've selected the wrong closure.
msg48761 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-29 21:05
Guido van Rossum suggests a vendor-packages directory in

I'm reopening the patch to encourage further review.
msg83873 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-03-20 22:30
Should be considered for 3.1 and 2.7.
msg113370 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 03:55
"Further review" never happened. Should be close this?
msg136314 - (view) Author: Danek Duvall (dhduvall) Date: 2011-05-19 16:54
So this has come up again within the Solaris group.  Since Rich's original request, we've been using a vendor-packages.pth file in the site-packages directory, which enables the vendor-packages directory.  However, I have a concern that this would completely disappear when Py_NoSiteFlag is enabled.  I would like to run the interpreter with -SE on all system-provided scripts, so that modules installed by the user in a private PYTHONPATH or in site-packages via easy_install (or similar) don't inadvertently interpose on system-provided modules which are the ones we've tested against.

I'm attaching a patch (against 2.6.4; sorry, haven't looked at anything newer yet) that modifies pythonrun.c to add initvendor() as a parallel with initmain() and initsite(), and is always run, regardless of Py_NoSiteFlag, but inserts vendor-packages after site-packages for when the user or a script is okay with the potential interposition.

If support for vendor-packages is being considered in general, I'd like to address the request for a rationale that has been brought up a handful of times before.  Specifically, distro vendors (such as ourselves) want to be able to deliver non-core python modules -- some written ourselves, some available from the community at large.  If we do that in the canonical site-packages directory, then those modules are at risk of being overwritten by local administrators installing python packages as they normally would.  This means that system programs -- including critical ones on Solaris, such as the packaging system -- might suddenly stop working.  If we separate the vendor space from the end-user space, then local admins can do anything they want without fear of breaking the system.  And if they really want to replace the vendor-supplied modules, then they can either go to the lengths of making the modules install in vendor-packages, or build using the same mechanisms we do (which for almost all the python we ship are still open-source) and install the resulting (system, not python) package.

I'd love feedback on my patch, regardless.
msg136651 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-05-23 14:48
Thanks for detailing the rationale.  Separating the “vendor”-controlled space (or let’s call it system; not all OSes have vendors :) from the sysadmin-controlled location is indeed a real concern, as shown by the recent-ish dist-packages invention by doko for Debian.  Maybe you could get more feedback from other Python packagers on the distutils-sig, python-dev or mailing list?
msg147608 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-14 16:47
> not all OSes have vendors
I realized that because French is my native language, I interpret “vendor” as “seller” (the meaning of “vendeur”), but I think that in English it just means “distributor” and has no relation with selling.  vendor-packages is arguably better that system-packages, as system can actually mean a lot of things.
msg147650 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-11-15 01:34
In English also, to vend is to sell, direct from Fr. *vendre*. However, ideas are not necessarily sold for money, but for assent, adoption, or other action. My dictionary has 'publish' as a secondary meaning of vend. So 'vendor-packages' is fine within the common metaphorical meaning of selling ideas. And it rolls off the tongue better than 'publisher-packages' or 'distributor-packages'.
msg186615 - (view) Author: Bohuslav "Slavek" Kabrda (bkabrda) * Date: 2013-04-12 10:35
I'm strongly +1 on this one. I package Python RPMs for Fedora and I know what mess can come out of installing through both RPM and easy_install/pip.
In Fedora, both Perl and Ruby use vendor specific dirs for installing RPM packaged modules and site specific dirs for installation via cpan/rubygems. Since I'm also Ruby maintainer, I was able to watch how the confusion of Ruby developers disappeared after we introduced this approach in Fedora 17 (and rubygems stopped uninstalling RPM gems, which was always causing unsatisfied dependency problems). So I think Python should also go this way and provide a configuration option to use vendor-packages. Please note, that Debian packagers have been patching their Python package downstream for quite some time, introducing "dist-packages" into their installation. I think that they didn't experience any significant problems so far, which pretty much proves that this is feasible (and also their patches could probably serve as a base for patch for cPython).
msg188373 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-05-04 15:51
Adding Nick to this discussion, since distutils-sig is talking about these issues right now.

Previous discussions:

Barry: if you could summarize how and why doko introduced dist-packages in Debian, or let me copy parts of email we exchanged a couple years ago, I think it could help.  Nick seems inclined to standardize doko’s solution, but IIRC it was an imperfect but working compromise, so we might want to rethink it.
msg188377 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2013-05-04 16:52
The discussion on distutils-sig that Éric is referring to is one were I ended up pointing out that PEP 439 (bootstrapping pip in 3.4) needs to address this in some manner, so that pip (which installs to site-packages) doesn't end up fighting with system package managers that are also installing to site-packages in many cases.

Since the distro vendors are in a better situation to change their target installation directory, the consensus on the list was that something *like* the current Debian solution is most appropriate (I wasn't aware this issue existed at the time).

The current situation is annoying-but-tolerable with pip as a third party solution, but unacceptable once the command is being provided by Python itself. As with virtual environments, something with upstream support may be able to be cleaner than a third party workaround.

Relevant distutils-sig post: (ignore the initial quoted part - I was just flat out wrong earlier in that thread)
msg188380 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-05-04 17:53
there is more than one thing addressed with the 'dist-packages' choice of name.

The primary reason is to have a directory where you only find python packages as distributed by the linux distribution, and where installers do not install to by default.  Even if this directory is non-writable, people did call 'sudo python install', and then did report issues on the Ubuntu tracker caused by these installs. Such a vendor place should never be the default to be installed to by default.

There is a Debian policy to support /usr/local, and that's the reason you find a second directory /usr/local/lib/pythonx.y/dist-packages. A 'sudo python install' installs into this location, distribution maintainers providing Debian packages are supposed to call install --install-layout=deb to install into the debian system installation.

At this time Barry still new to distro policies, was surprised to find /usr/local/lib/pythonx.y/site-packages being used by the system python, which is also used by a local python build which is configured without any --prefix parameters. So the system python now uses dist-packages in both /usr and /usr/local to not interfere with a local python installation.

Note that for python3, Debian and Ubuntu are trying to share dist-packages across python3 versions to ease upgrades from one version to the other, and trying to support more than one version during the upgrade (calling that /usr/lib/python3/dist-packages).
msg214807 - (view) Author: Robert Kuska (rkuska) * Date: 2014-03-25 10:44
There is ongoing discussion on pip's github tracker [1] about default location where to install user modules. 

IMO this is something that should be dealt with in Python Interpreter Core [2][3]. I would like to hear some opinion from python devs on this.

msg214821 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-03-25 12:48
Note that authority over package design decisions has been delegated to the Python Packaging Authority - it's up to them to decide what they want and ask for it (of they decide they actually need modifications to the interpreter), not for Python core to tell them what to do.
msg215306 - (view) Author: Robert Kuska (rkuska) * Date: 2014-04-01 11:38
Ok, I have started a thread at pypa-devs google group.!topic/pypa-dev/r6qsAmJl9t0
Date User Action Args
2022-04-11 14:56:13adminsetgithub: 42401
2019-12-19 00:30:17brett.cannonsetnosy: - brett.cannon
2015-04-29 20:22:05jbecksetnosy: + jbeck
2014-04-01 11:38:02rkuskasetmessages: + msg215306
2014-03-25 19:57:53terry.reedysetstage: patch review
versions: + Python 3.5, - Python 3.4
2014-03-25 12:49:14piotr.dobrogostsetnosy: + piotr.dobrogost
2014-03-25 12:48:18ncoghlansetmessages: + msg214821
2014-03-25 10:44:23rkuskasetnosy: + rkuska
messages: + msg214807
2013-05-04 17:53:11dokosetmessages: + msg188380
2013-05-04 16:52:52ncoghlansetnosy: + richard
messages: + msg188377
2013-05-04 15:51:57eric.araujosetcomponents: + Interpreter Core, - Library (Lib), Distutils2
versions: + Python 3.4, - Python 3.3
2013-05-04 15:51:33eric.araujosetassignee: tarek ->

messages: + msg188373
nosy: + ncoghlan
2013-04-12 10:35:24bkabrdasetnosy: + bkabrda
messages: + msg186615
2013-01-27 22:06:13trentsetnosy: + trent, brian-cameron-oracle
2011-11-15 01:34:20terry.reedysetmessages: + msg147650
2011-11-14 16:47:16eric.araujosetmessages: + msg147608
2011-05-23 14:48:21eric.araujosettitle: vendor-packages directory. -> Add a vendor-packages directory for system-supplied modules
nosy: + carljm, barry, brett.cannon, eric.araujo, alexis, doko

messages: + msg136651

versions: + Python 3.3, - Python 3.2
components: + Distutils2
2011-05-19 16:54:25dhduvallsetfiles: + vps.diff
nosy: + dhduvall
messages: + msg136314

2010-08-09 03:55:07terry.reedysetmessages: + msg113370
versions: + Python 3.2, - Python 3.1, Python 2.7
2009-04-05 14:32:21georg.brandlsetassignee: tarek

nosy: + tarek
2009-03-20 22:30:24ajaksu2setversions: + Python 3.1, Python 2.7, - Python 2.4
nosy: + ajaksu2

messages: + msg83873

type: enhancement
2005-09-22 15:12:42richburridgecreate