Created on 2005-09-22 15:12 by richburridge, last changed 2013-05-04 17:53 by doko.
|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|
|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. See: http://mail.python.org/pipermail/python-list/2005-September/300029.html 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 python.org> Reply-To: Guido van Rossum <guido at python.org> To: Rich Burridge <Rich.Burridge at Sun.COM> References: <4330C108.firstname.lastname@example.org> 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. --Guido
|msg48759 - (view)||Author: Terry J. Reedy (terry.reedy) *||Date: 2005-09-23 23:49|
Logged In: YES user_id=593130 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 http://mail.python.org/pipermail/python-dev/2005- September/056682.html A subsequent post http://mail.python.org/pipermail/python-dev/2005- September/056696.html 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 http://mail.python.org/pipermail/python-dev/2005- September/056697.html and here http://mail.python.org/pipermail/python-dev/2005- September/056702.html 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 user_id=511506 A good alternative solution to this problem was given on the python-devel mailing list. See: http://mail.python.org/pipermail/python-dev/2005-September/056697.html http://mail.python.org/pipermail/python-dev/2005-September/056699.html 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) *||Date: 2006-11-29 21:05|
Guido van Rossum suggests a vendor-packages directory in http://mail.python.org/pipermail/python-dev/2006-November/070063.html I'm reopening the patch to encourage further review.
|msg83873 - (view)||Author: Daniel Diniz (ajaksu2)||Date: 2009-03-20 22:30|
Should be considered for 3.1 and 2.7.
|msg113370 - (view)||Author: Terry J. Reedy (terry.reedy) *||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) *||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 email@example.com mailing list?
|msg147608 - (view)||Author: Éric Araujo (eric.araujo) *||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) *||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) *||Date: 2013-05-04 15:51|
Adding Nick to this discussion, since distutils-sig is talking about these issues right now. Previous discussions: http://mail.python.org/pipermail/python-list/2005-September/345116.html http://mail.python.org/pipermail/python-dev/2005-September/056682.html http://mail.python.org/pipermail/python-dev/2003-August/037487.html 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) *||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:http://mail.python.org/pipermail/distutils-sig/2013-May/020673.html (ignore the initial quoted part - I was just flat out wrong earlier in that thread)
|msg188380 - (view)||Author: Matthias Klose (doko) *||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 setup.py 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 setup.py install' installs into this location, distribution maintainers providing Debian packages are supposed to call setup.py 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).
|2013-05-04 17:53:11||doko||set||messages: + msg188380|
messages: + msg188377
+ Interpreter Core, - Library (Lib), Distutils2|
versions: + Python 3.4, - Python 3.3
|2013-05-04 15:51:33||eric.araujo||set||assignee: tarek -> |
messages: + msg188373
nosy: + ncoghlan
messages: + msg186615
+ trent, brian-cameron-oracle|
|2011-11-15 01:34:20||terry.reedy||set||messages: + msg147650|
|2011-11-14 16:47:16||eric.araujo||set||messages: + msg147608|
|2011-05-23 14:48:21||eric.araujo||set||title: 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
nosy: + dhduvall
messages: + msg136314
versions: + Python 3.2, - Python 3.1, Python 2.7
|2009-04-05 14:32:21||georg.brandl||set||assignee: tarek|
nosy: + tarek
+ Python 3.1, Python 2.7, - Python 2.4|
nosy: + ajaksu2
messages: + msg83873