From nad at acm.org Mon Sep 9 21:19:26 2013 From: nad at acm.org (Ned Deily) Date: Mon, 09 Sep 2013 12:19:26 -0700 Subject: [Pythonmac-SIG] Python 3.4.0 alpha 2 available Message-ID: I would like call your attention to the latest alpha release of Python 3.4.0 and a new batteries-included feature for OS X users. For 3.4.0.a2, the python.org 64-bit/32-bit installer now includes its own private version of Tcl/Tk 8.5.14 so it is no longer necessary to install a third-party version of Tcl/Tk 8.5 to workaround the problematic system versions shipped in OS X 10.6+. Unlike Pythons from previous installers, only this private version will be used by tkinter and IDLE. It will have no effect on or be affected by any other versions of Tcl/Tk installed on your system, such as ActivelTcl 8.5.x or Apple 8.5.x. Since this is a new feature and somewhat experimental, it may change prior to the official release of Python 3.4.0, planned for 2014-02. There will be other OS X installer-related changes coming. Please report any problems or issues you encounter to the Python bug tracker. Thanks! http://www.python.org/download/releases/3.4.0/ http://www.python.org/download/mac/tcltk/ http://bugs.python.org -- Ned Deily, nad at acm.org From nathaniel.echols at gmail.com Wed Sep 11 04:54:52 2013 From: nathaniel.echols at gmail.com (Nat Echols) Date: Tue, 10 Sep 2013 19:54:52 -0700 Subject: [Pythonmac-SIG] avoiding system's "easy-install.pth" with custom distribution Message-ID: 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? thanks, Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at acm.org Wed Sep 11 08:16:40 2013 From: nad at acm.org (Ned Deily) Date: Tue, 10 Sep 2013 23:16:40 -0700 Subject: [Pythonmac-SIG] avoiding system's "easy-install.pth" with custom distribution References: Message-ID: In article , Nat Echols 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. 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, nad at acm.org From chris.barker at noaa.gov Thu Sep 12 04:28:41 2013 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 11 Sep 2013 19:28:41 -0700 Subject: [Pythonmac-SIG] avoiding system's "easy-install.pth" with custom distribution In-Reply-To: References: Message-ID: On Tue, Sep 10, 2013 at 11:16 PM, Ned Deily wrote: > 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 yeah, probably not.... > 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. > > Could you simply remove it from sys.path at start-up for your app? (probably when you toss out PYTHONPATH) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Thu Sep 12 12:00:08 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 12 Sep 2013 12:00:08 +0200 Subject: [Pythonmac-SIG] avoiding system's "easy-install.pth" with custom distribution In-Reply-To: References: Message-ID: <31DC4033-687E-43BF-AEDA-02A7687A63E7@mac.com> On 11 Sep, 2013, at 8:16, Ned Deily wrote: > In article > , > Nat Echols 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, > nad at acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From nathaniel.echols at gmail.com Fri Sep 13 22:01:07 2013 From: nathaniel.echols at gmail.com (Nat Echols) Date: Fri, 13 Sep 2013 13:01:07 -0700 Subject: [Pythonmac-SIG] avoiding system's "easy-install.pth" with custom distribution In-Reply-To: References: Message-ID: On Tue, Sep 10, 2013 at 11:16 PM, Ned Deily wrote: > 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). Wow, okay. 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. > Unfortunately I am stuck with 2.7.x for the indefinite future, but since we already maintain our own minor patches to the Python sources, I do not mind adjusting this myself. 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. > Excellent, I'll try this. Modifying sys.path on the fly as Chris suggests is possible as well, although the PYTHONPATH erasure is actually handled by shell scripts which actually launch the programs. thanks, Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: