On 11 Sep, 2013, at 8:16, Ned Deily <n...@acm.org> wrote: > In article > <calzqqjbkh5cwrf6hpclc7nurkmbajutr3tyro_wqxjzl9vv...@mail.gmail.com>, > Nat Echols <nathaniel.ech...@gmail.com> wrote: >> I'm distributing a large cross-platform Python-based application, for which >> we bundle Python 2.7 and a number of dependencies (wxPython, matplotlib, >> etc.). We've tried to make it as self-contained as possible, to prevent >> either a) polluting the user's environment and potentially breaking other >> programs, or b) breaking our program because other software pollutes the >> environment. This means wiping out PYTHONPATH at runtime, which has worked >> quite well for us. >> >> What I've now discovered is that at least on OS 10.7.5, if a user installs >> packages for the system python using easy_install (possibly other >> mechanisms as well, but that's what "worked" for me), these will now end up >> in the search path for our app's python interpreter, and override many of >> the packages we distribute because they appear relatively early in >> sys.path. The problem appears to be traceable to this file: >> >> /Library/Python/2.7/site-packages/easy-install.pth >> >> which modifies sys.path directly. Removing or renaming that file leaves >> our custom distribution's path alone. So, two questions: >> >> 1) Why is this happening? It seems incredibly broken - but I have no idea >> who's fault it is, for all I know we're doing something foolish when we >> compile Python on our build system (10.6, if it matters). >> >> 2) Is there any way we can modify our distribution to avoid this? > > The behavior is the result of a feature added in 2.7 for Issue4865 which > appends the site-packages directory for the Apple-supplied system Python > to sys.path of a Python framework build. With hindsight, I don't think > this was a good idea and you are not the first to complain about it > (see, for instance, Issue15048). OTOH, as Ronald pointed out in that > issue, there isn't a complete separation between Python frameworks > anyway: they all share the user site-packages directory > (~/Library/Python for a framework build) and configuration files (like > for Distutils and IDLE). It is late in the game to make a change like > this in Python 2.7.x which is nearing the end of its supported life. > It's not too late, IMO, to change current Python 3 before it becomes an > issue; it's not an issue yet because Apple has not yet shipped anything > newer than Python 2.7.x. Feel free to chime in on the bug tracker.
Personaly I'd just drop support for ~/Library/Python and /Library/Python in 3.4, while keeping support for ~/.local (as used by the non-framework build and other unix platforms). This moves framework builds closer to normal unix builds, and makes it less likely that a (hypothetical) Apple 3.4 install causes problems with the Python.org provided install. The disadvantage is that ~/.local is ugly as hell and doesn't fit nicely in the OSX filesystem hierarchy standard but that's something I'll have to learn to live with. With built-in support for virtual environments even the per-user install directory could be removed, but that is a much larger change that requires a PEP and clear argumentation as to why this is a good idea (and even then it probably wouldn't pass on python-dev). Ronald > > The path appends occur in the standard library "site" module. You could > patch it in your own interpreter to not include /Library/Python; you > might be also be able to do it by supplying a "sitecustomize" module. > See site.py for details. > > http://bugs.python.org/issue4865 > http://bugs.python.org/issue15048 > http://hg.python.org/cpython/file/2.7/Lib/site.py#l305 > > -- > Ned Deily, > n...@acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG