Message136314
| Author |
dhduvall |
| Recipients |
ajaksu2, dhduvall, loewis, richburridge, tarek, terry.reedy |
| Date |
2011年05月19日.16:54:24 |
| SpamBayes Score |
2.867151e-13 |
| Marked as misclassified |
No |
| Message-id |
<1305824066.62.0.799476994572.issue1298835@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|