pyobjc-dev Mailing List for PyObjC (Page 8)
Brought to you by:
ronaldoussoren
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(30) |
May
(18) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
|
Sep
(23) |
Oct
(180) |
Nov
(291) |
Dec
(95) |
2003 |
Jan
(338) |
Feb
(352) |
Mar
(97) |
Apr
(46) |
May
(226) |
Jun
(184) |
Jul
(145) |
Aug
(141) |
Sep
(69) |
Oct
(161) |
Nov
(96) |
Dec
(90) |
2004 |
Jan
(66) |
Feb
(87) |
Mar
(98) |
Apr
(132) |
May
(115) |
Jun
(68) |
Jul
(150) |
Aug
(92) |
Sep
(59) |
Oct
(52) |
Nov
(17) |
Dec
(75) |
2005 |
Jan
(84) |
Feb
(191) |
Mar
(133) |
Apr
(114) |
May
(158) |
Jun
(185) |
Jul
(62) |
Aug
(28) |
Sep
(36) |
Oct
(88) |
Nov
(65) |
Dec
(43) |
2006 |
Jan
(85) |
Feb
(62) |
Mar
(92) |
Apr
(75) |
May
(68) |
Jun
(101) |
Jul
(73) |
Aug
(37) |
Sep
(91) |
Oct
(65) |
Nov
(30) |
Dec
(39) |
2007 |
Jan
(24) |
Feb
(28) |
Mar
(10) |
Apr
(2) |
May
(18) |
Jun
(16) |
Jul
(21) |
Aug
(6) |
Sep
(30) |
Oct
(31) |
Nov
(153) |
Dec
(31) |
2008 |
Jan
(63) |
Feb
(70) |
Mar
(47) |
Apr
(24) |
May
(59) |
Jun
(22) |
Jul
(12) |
Aug
(7) |
Sep
(14) |
Oct
(26) |
Nov
(5) |
Dec
(5) |
2009 |
Jan
(10) |
Feb
(41) |
Mar
(70) |
Apr
(88) |
May
(49) |
Jun
(62) |
Jul
(34) |
Aug
(15) |
Sep
(55) |
Oct
(40) |
Nov
(67) |
Dec
(21) |
2010 |
Jan
(60) |
Feb
(17) |
Mar
(26) |
Apr
(26) |
May
(29) |
Jun
(4) |
Jul
(21) |
Aug
(21) |
Sep
(10) |
Oct
(12) |
Nov
(3) |
Dec
(19) |
2011 |
Jan
(3) |
Feb
(13) |
Mar
(8) |
Apr
(8) |
May
(17) |
Jun
(20) |
Jul
(21) |
Aug
(7) |
Sep
|
Oct
|
Nov
(9) |
Dec
(11) |
2012 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
(14) |
Jul
(5) |
Aug
(2) |
Sep
(15) |
Oct
(2) |
Nov
(23) |
Dec
(1) |
2013 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
(12) |
Nov
(10) |
Dec
(3) |
2014 |
Jan
(7) |
Feb
(14) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(11) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(1) |
Dec
(2) |
2015 |
Jan
(9) |
Feb
(7) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2016 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(21) |
Oct
(17) |
Nov
|
Dec
(36) |
2017 |
Jan
(6) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
2018 |
Jan
(2) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(2) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(6) |
Oct
(16) |
Nov
(1) |
Dec
(6) |
2019 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ronald O. <ron...@ma...> - 2016-10-11 21:39:53
|
Hi, Finishing Sierra support in PyObjC is taking more time than expected, mostly due to lack of time on my part but also due to some unexpected test failures (in particular, a number of less used framework wrappers crash during testing on 10.12). I’ve pushed the initial batch of 10.12 updates to bitbucket. Those contain the majority of the 10.12 support, but this needs more work before I can perform a release. Also: metadata updates were done using a prerelease version of the 10.12 SDK, there may be missing symbols because of that. Ronald |
From: Ronald O. <ron...@ma...> - 2016-10-11 21:26:21
|
> On 17 Sep 2016, at 19:59, Glyph Lefkowitz <gl...@tw...> wrote: > >> >> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >> >> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>>> <mailto:a.h...@gm...>> wrote: >>>> >>>> Aha! >>>> >>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>> total 0 >>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>> >>>> Now I wonder how those got there?! >>>> >>> >>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>> prediction about setuptools' behavior :) >> >> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >> Extras.pth file in /Library/Python/2.7; it's something new. And, >> unfortunately, due to https://bugs.python.org/issue4865, the >> site-packages directory for the system Python 2.7 is included in >> sys.path along with the non-system framework Python site-packages. > > Hrm. I guess everyone I knew on the beta was using homebrew python :(. > > I'm surprised that Apple is putting stuff in /Library. I don't have a Sierra box handy - /Library isn't SIP-protected now, is it? > > This seems wrong; someone should file a radar (and probably share on http://www.openradar.me <http://www.openradar.me/> for further discussion). Did someone file a radar for this? Otherwise I can do so. I can affirm that Extras.pth is now in /Library/Python/2.7 instead of in a system location. This sucks as bits of the system install now infect other installs of Python 2.7. One more reason to stop using 2.7 I guess ;-) BTW. Has anyone experience with using LLDB on Sierra? I’m currently running Sierra in a VM and for some reason LLDB doesn’t appear to work, in an SSH session I cannot start programs at all and on the console a crashing bug in the interpreter exists the interpreter instead of breaking into the debugger. That’s rather annoying when you’re trying to a debug a crash on 10.12 that doesn’t happen on 10.11. Ronald > > -glyph > > > ------------------------------------------------------------------------------ > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... <mailto:Pyo...@li...> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev <https://lists.sourceforge.net/lists/listinfo/pyobjc-dev> |
From: Glyph L. <gl...@tw...> - 2016-10-07 09:03:51
|
> On Oct 7, 2016, at 1:36 AM, Andrew Jaffe <a.h...@gm...> wrote: > > On 06/10/2016 20:26, Glyph Lefkowitz wrote: >>> On Oct 6, 2016, at 2:56 AM, Andrew Jaffe wrote: >>> On 17/09/2016 18:59, Glyph Lefkowitz wrote: >>>>> On Sep 17, 2016, at 9:27 AM, Ned Deily wrote: >>>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe wrote: >>>>>>> >>>>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>>>> total 0 >>>>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>>>> >>>>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>>>> prediction about setuptools' behavior :) >>>>> >>>>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>>>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>>>> unfortunately, due to https://bugs.python.org/issue4865, the >>>>> site-packages directory for the system Python 2.7 is included in >>>>> sys.path along with the non-system framework Python site-packages. >>>> >>> So, a little more data: >>> >>> If you rename or remove /Library/Python/2.7/site-packages/Extras.pth >>> then pip2 works. >> >> What do you mean by "works"? Your original error is pip refusing to >> upgrade pyObjC because to upgrade pyObjC it has to delete the old >> version, and pyObjC is part of the operating system, and it can't delete >> the installed version. This is correct; the error reporting could be >> nicer, but pip is not broken. Don't mess with files in /System. >> >> The suggestion to use virtualenv isn't really optional. If you really, >> really want things to be importable by a bare 'python', not inside a >> venv, `pip install --user` is another option you might have. >> >>> *However*, lots of other stuff breaks -- anything that uses Apple's >>> python and relies on access to pyobjc and the frameworks (e.g., >>> TextMate's latex package). >> >> Yep, that's expected behavior. This is exactly why Apple is making it >> increasingly difficult to screw up /System. Apps can, should, and do >> rely upon the libraries installed on the system. >> >>> What I don't understand is: what changed from Yosemite? This file did >>> not exist before Sierra, but there were no problems with (Apple) >>> python accessing these packages. >> >> Do you mean from El Capitan? > > Yes, sorry. > >> This file previously existed in a different location, and (while the >> particulars stubbornly refuse to stick to memory for me, for some >> reason) this new location is the one generally preferred by the python >> packaging maintainers. >> >>> (Or is there something unique in my setup that is causing this? I kind >>> of doubt it, but it's possible...) >>> >>> Does anyone have any insight? >> >> If you really, really, really want to do this in such a way that /System >> stuff is only present for /System's python and not for python.org >> <http://python.org>'s, you can take advantage of the 'import' hack >> <https://docs.python.org/2/library/site.html>, and >> rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_ >> add those entries to sys.path, checking sys.executable or some other >> fingerprint. >> >> But: don't. Given that system python and python.org <http://python.org> >> python share /Library and ~/Library, they're not /really/ distinct >> environments, and things installed into one will show up in the other, >> so excluding the /System directories on one but not the other will just >> cause other, more confusing issues. >> >> In conclusion: just use virtualenv. This is not a problem that should >> be fixed. > > I agree that this would solve all of the problems, at the cost of some minor startup pain. > > But one nice thing about the python.org builds is that, for the last few releases, they just worked out of the box, where by "worked" I mean that (as far as I can tell) the system Python saw its own packages, and the python.org build saw its own packages, and (python.org) pip didn't seem to care about the system files. Trust me, they didn't just work :). There were numerous potential misconfigurations that dealt with conflicts between system python packages and user-installed packages. Installing stuff into the global environment has always been a bad idea. Some system files would be on the path, some wouldn't, and things installed into one environment would bleed over into the other. > And I suppose I still don't understand exactly why that changed with Sierra, and whether the change is actually beneficial in any way whatever! (And whether it could only be fixed by Apple, or whether a change in the python.org build could do something about it.) I'm not sure as to the exact difference, but my basic understanding is that rather than failing silently and ignoring system-installed stuff, pip now reliably and correctly fails to upgrade system packages that are protected by SIP. > Sorry to keep harping on about it, but I find it hard to believe this is not a fairly widespread problem! (Well, I found at least one other complaint: https://jasonkratz.com/2016/09/25/python-2-7-on-the-mac-site-package-weirdness/) The problem is that we're not properly getting the message out about how to set up Python for development; venvs are increasingly graduating from "best practice" to "necessary to function", but I don't think users are getting the message. (Case in point: this thread is still going :).) System packages are for system developers. If you aren't shipping Python.org python itself, or working for apple on OS X, you should not be installing things into /Library or even as a user with *permission* to install things into /Library. -glyph |
From: Andrew J. <a.h...@gm...> - 2016-10-07 08:36:41
|
On 06/10/2016 20:26, Glyph Lefkowitz wrote: >> On Oct 6, 2016, at 2:56 AM, Andrew Jaffe wrote: >> On 17/09/2016 18:59, Glyph Lefkowitz wrote: >>>> On Sep 17, 2016, at 9:27 AM, Ned Deily wrote: >>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe wrote: >>>>>> >>>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>>> total 0 >>>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>>> >>>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>>> prediction about setuptools' behavior :) >>>> >>>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>>> unfortunately, due to https://bugs.python.org/issue4865, the >>>> site-packages directory for the system Python 2.7 is included in >>>> sys.path along with the non-system framework Python site-packages. >>> >> So, a little more data: >> >> If you rename or remove /Library/Python/2.7/site-packages/Extras.pth >> then pip2 works. > > What do you mean by "works"? Your original error is pip refusing to > upgrade pyObjC because to upgrade pyObjC it has to delete the old > version, and pyObjC is part of the operating system, and it can't delete > the installed version. This is correct; the error reporting could be > nicer, but pip is not broken. Don't mess with files in /System. > > The suggestion to use virtualenv isn't really optional. If you really, > really want things to be importable by a bare 'python', not inside a > venv, `pip install --user` is another option you might have. > >> *However*, lots of other stuff breaks -- anything that uses Apple's >> python and relies on access to pyobjc and the frameworks (e.g., >> TextMate's latex package). > > Yep, that's expected behavior. This is exactly why Apple is making it > increasingly difficult to screw up /System. Apps can, should, and do > rely upon the libraries installed on the system. > >> What I don't understand is: what changed from Yosemite? This file did >> not exist before Sierra, but there were no problems with (Apple) >> python accessing these packages. > > Do you mean from El Capitan? Yes, sorry. > This file previously existed in a different location, and (while the > particulars stubbornly refuse to stick to memory for me, for some > reason) this new location is the one generally preferred by the python > packaging maintainers. > >> (Or is there something unique in my setup that is causing this? I kind >> of doubt it, but it's possible...) >> >> Does anyone have any insight? > > If you really, really, really want to do this in such a way that /System > stuff is only present for /System's python and not for python.org > <http://python.org>'s, you can take advantage of the 'import' hack > <https://docs.python.org/2/library/site.html>, and > rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_ > add those entries to sys.path, checking sys.executable or some other > fingerprint. > > But: don't. Given that system python and python.org <http://python.org> > python share /Library and ~/Library, they're not /really/ distinct > environments, and things installed into one will show up in the other, > so excluding the /System directories on one but not the other will just > cause other, more confusing issues. > > In conclusion: just use virtualenv. This is not a problem that should > be fixed. I agree that this would solve all of the problems, at the cost of some minor startup pain. But one nice thing about the python.org builds is that, for the last few releases, they just worked out of the box, where by "worked" I mean that (as far as I can tell) the system Python saw its own packages, and the python.org build saw its own packages, and (python.org) pip didn't seem to care about the system files. And I suppose I still don't understand exactly why that changed with Sierra, and whether the change is actually beneficial in any way whatever! (And whether it could only be fixed by Apple, or whether a change in the python.org build could do something about it.) Sorry to keep harping on about it, but I find it hard to believe this is not a fairly widespread problem! (Well, I found at least one other complaint: https://jasonkratz.com/2016/09/25/python-2-7-on-the-mac-site-package-weirdness/) Andrew |
From: Glyph L. <gl...@tw...> - 2016-10-06 19:26:35
|
> On Oct 6, 2016, at 2:56 AM, Andrew Jaffe <a.h...@gm...> wrote: > > On 17/09/2016 18:59, Glyph Lefkowitz wrote: >> >>> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >>> >>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>>>> <mailto:a.h...@gm...>> wrote: >>>>> >>>>> Aha! >>>>> >>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>> total 0 >>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>> >>>>> Now I wonder how those got there?! >>>>> >>>> >>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>> prediction about setuptools' behavior :) >>> >>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>> unfortunately, due to https://bugs.python.org/issue4865, the >>> site-packages directory for the system Python 2.7 is included in >>> sys.path along with the non-system framework Python site-packages. >> > > > > > So, a little more data: > > If you rename or remove /Library/Python/2.7/site-packages/Extras.pth then pip2 works. What do you mean by "works"? Your original error is pip refusing to upgrade pyObjC because to upgrade pyObjC it has to delete the old version, and pyObjC is part of the operating system, and it can't delete the installed version. This is correct; the error reporting could be nicer, but pip is not broken. Don't mess with files in /System. The suggestion to use virtualenv isn't really optional. If you really, really want things to be importable by a bare 'python', not inside a venv, `pip install --user` is another option you might have. > *However*, lots of other stuff breaks -- anything that uses Apple's python and relies on access to pyobjc and the frameworks (e.g., TextMate's latex package). Yep, that's expected behavior. This is exactly why Apple is making it increasingly difficult to screw up /System. Apps can, should, and do rely upon the libraries installed on the system. > What I don't understand is: what changed from Yosemite? This file did not exist before Sierra, but there were no problems with (Apple) python accessing these packages. Do you mean from El Capitan? This file previously existed in a different location, and (while the particulars stubbornly refuse to stick to memory for me, for some reason) this new location is the one generally preferred by the python packaging maintainers. > (Or is there something unique in my setup that is causing this? I kind of doubt it, but it's possible...) > > Does anyone have any insight? If you really, really, really want to do this in such a way that /System stuff is only present for /System's python and not for python.org's, you can take advantage of the 'import' hack <https://docs.python.org/2/library/site.html>, and rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_ add those entries to sys.path, checking sys.executable or some other fingerprint. But: don't. Given that system python and python.org python share /Library and ~/Library, they're not really distinct environments, and things installed into one will show up in the other, so excluding the /System directories on one but not the other will just cause other, more confusing issues. In conclusion: just use virtualenv. This is not a problem that should be fixed. -glyph |
From: Andrew J. <a.h...@gm...> - 2016-10-06 09:56:17
|
On 17/09/2016 18:59, Glyph Lefkowitz wrote: > >> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >> >> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>>> <mailto:a.h...@gm...>> wrote: >>>> >>>> Aha! >>>> >>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>> total 0 >>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>> >>>> Now I wonder how those got there?! >>>> >>> >>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>> prediction about setuptools' behavior :) >> >> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >> Extras.pth file in /Library/Python/2.7; it's something new. And, >> unfortunately, due to https://bugs.python.org/issue4865, the >> site-packages directory for the system Python 2.7 is included in >> sys.path along with the non-system framework Python site-packages. > > So, a little more data: If you rename or remove /Library/Python/2.7/site-packages/Extras.pth then pip2 works. *However*, lots of other stuff breaks -- anything that uses Apple's python and relies on access to pyobjc and the frameworks (e.g., TextMate's latex package). What I don't understand is: what changed from Yosemite? This file did not exist before Sierra, but there were no problems with (Apple) python accessing these packages. (Or is there something unique in my setup that is causing this? I kind of doubt it, but it's possible...) Does anyone have any insight? Thanks, Andrew |
From: Glyph L. <gl...@tw...> - 2016-09-21 09:48:32
|
> On Sep 21, 2016, at 01:52, Andrew Jaffe <a.h...@gm...> wrote: > > That would work, and in fact I don't really need PyObjC (sorry, Ronald!) but I've got my whole setup working with the "global" python.org <http://python.org/> framework build, so I am used to that... and the Sierra status quo does seem ugly (and quite possibly is a bug!). Well, Apple ships certain libraries, and they want them to be on your path. The nice thing about virtualenv is that, along with pip wheel caching, re-creating them is really fast, so you don't have to just do one setup; you just make a requirements.txt for each separate environment you want, and regularly re-create it, so you know that if you give directions to anyone else, your setup will work for them as well. One bad habit we get into is getting a full-on environment set up on our own workstation, and then not knowing exactly what we installed, and therefore what we need in order for someone else to build and work on our software. Virtualenv helps reduce that problem a bit. -glyph |
From: Andrew J. <a.h...@gm...> - 2016-09-21 08:52:36
|
On 20/09/2016 20:54, Glyph Lefkowitz wrote: >> On Sep 20, 2016, at 10:29 AM, Andrew Jaffe <a.h...@gm...> wrote: >> >> On 17/09/2016 18:59, Glyph Lefkowitz wrote: >>> >>>> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >>>> >>>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm...> wrote: >>>>>> >>>>>> Aha! >>>>>> >>>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>>> total 0 >>>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>>> >>>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>>> prediction about setuptools' behavior :) >>>> >>>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>>> unfortunately, due to https://bugs.python.org/issue4865, the >>>> site-packages directory for the system Python 2.7 is included in >>>> sys.path along with the non-system framework Python site-packages. >>> >>> This seems wrong; someone should file a radar (and probably share >>> on http://www.openradar.me <http://www.openradar.me/> for further >>> discussion). >> >> In the meantime, what's the recommended workaround? > > Looking back over the thread, my first reply was: "Make a virtualenv and > install pyobjc there", but I didn't see a direct response to that. That > would still be my first choice for a workaround. Is there some reason > that doesn't work for you? That would work, and in fact I don't really need PyObjC (sorry, Ronald!) but I've got my whole setup working with the "global" python.org framework build, so I am used to that... and the Sierra status quo does seem ugly (and quite possibly is a bug!). Andrew |
From: Glyph L. <gl...@tw...> - 2016-09-20 19:54:34
|
> On Sep 20, 2016, at 10:29 AM, Andrew Jaffe <a.h...@gm...> wrote: > > On 17/09/2016 18:59, Glyph Lefkowitz wrote: >> >>> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >>> >>> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>>>> <mailto:a.h...@gm...>> wrote: >>>>> >>>>> Aha! >>>>> >>>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>>> total 0 >>>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>>> >>>>> Now I wonder how those got there?! >>>>> >>>> >>>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>>> prediction about setuptools' behavior :) >>> >>> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >>> Extras.pth file in /Library/Python/2.7; it's something new. And, >>> unfortunately, due to https://bugs.python.org/issue4865, the >>> site-packages directory for the system Python 2.7 is included in >>> sys.path along with the non-system framework Python site-packages. >> >> Hrm. I guess everyone I knew on the beta was using homebrew python :(. >> >> I'm surprised that Apple is putting stuff in /Library. I don't have a Sierra box handy - /Library isn't SIP-protected now, is it? > > Nope, that's not a problem. >> >> This seems wrong; someone should file a radar (and probably share on http://www.openradar.me <http://www.openradar.me/> for further discussion). > > In the meantime, what's the recommended workaround? Looking back over the thread, my first reply was: "Make a virtualenv and install pyobjc there", but I didn't see a direct response to that. That would still be my first choice for a workaround. Is there some reason that doesn't work for you? -glyph |
From: Andrew J. <a.h...@gm...> - 2016-09-20 17:29:32
|
On 17/09/2016 18:59, Glyph Lefkowitz wrote: > >> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: >> >> On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>>> <mailto:a.h...@gm...>> wrote: >>>> >>>> Aha! >>>> >>>> $ ls -lt /Library/Python/2.7/site-packages/ >>>> total 0 >>>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>>> $ more /Library/Python/2.7/site-packages/Extras.pth >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>>> >>>> Now I wonder how those got there?! >>>> >>> >>> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >>> prediction about setuptools' behavior :) >> >> This seems to be Apple's doing. AFAICT, 10.12 is shipping with this >> Extras.pth file in /Library/Python/2.7; it's something new. And, >> unfortunately, due to https://bugs.python.org/issue4865, the >> site-packages directory for the system Python 2.7 is included in >> sys.path along with the non-system framework Python site-packages. > > Hrm. I guess everyone I knew on the beta was using homebrew python :(. > > I'm surprised that Apple is putting stuff in /Library. I don't have a Sierra box handy - /Library isn't SIP-protected now, is it? Nope, that's not a problem. > > This seems wrong; someone should file a radar (and probably share on http://www.openradar.me for further discussion). In the meantime, what's the recommended workaround? A |
From: Glyph L. <gl...@tw...> - 2016-09-17 17:59:10
|
> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py...> wrote: > > On 2016-09-13 19:33, Glyph Lefkowitz wrote: >>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >>> <mailto:a.h...@gm...>> wrote: >>> >>> Aha! >>> >>> $ ls -lt /Library/Python/2.7/site-packages/ >>> total 0 >>> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >>> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >>> $ more /Library/Python/2.7/site-packages/Extras.pth >>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >>> >>> Now I wonder how those got there?! >>> >> >> Hah! Thanks for sharing. Very satisfying to actually make a *correct* >> prediction about setuptools' behavior :) > > This seems to be Apple's doing. AFAICT, 10.12 is shipping with this > Extras.pth file in /Library/Python/2.7; it's something new. And, > unfortunately, due to https://bugs.python.org/issue4865, the > site-packages directory for the system Python 2.7 is included in > sys.path along with the non-system framework Python site-packages. Hrm. I guess everyone I knew on the beta was using homebrew python :(. I'm surprised that Apple is putting stuff in /Library. I don't have a Sierra box handy - /Library isn't SIP-protected now, is it? This seems wrong; someone should file a radar (and probably share on http://www.openradar.me for further discussion). -glyph |
From: Ned D. <na...@py...> - 2016-09-17 16:30:25
|
On 2016-09-13 19:33, Glyph Lefkowitz wrote: >> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm... >> <mailto:a.h...@gm...>> wrote: >> >> Aha! >> >> $ ls -lt /Library/Python/2.7/site-packages/ >> total 0 >> -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* >> -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README >> $ more /Library/Python/2.7/site-packages/Extras.pth >> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python >> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC >> >> Now I wonder how those got there?! >> > > Hah! Thanks for sharing. Very satisfying to actually make a *correct* > prediction about setuptools' behavior :) This seems to be Apple's doing. AFAICT, 10.12 is shipping with this Extras.pth file in /Library/Python/2.7; it's something new. And, unfortunately, due to https://bugs.python.org/issue4865, the site-packages directory for the system Python 2.7 is included in sys.path along with the non-system framework Python site-packages. |
From: Glyph L. <gl...@tw...> - 2016-09-13 23:33:49
|
> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe <a.h...@gm...> wrote: > > Aha! > > $ ls -lt /Library/Python/2.7/site-packages/ > total 0 > -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* > -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README > $ more /Library/Python/2.7/site-packages/Extras.pth > /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python > /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC > > Now I wonder how those got there?! > Hah! Thanks for sharing. Very satisfying to actually make a *correct* prediction about setuptools' behavior :) -glyph |
From: Andrew J. <a.h...@gm...> - 2016-09-13 22:36:07
|
Hi, > On 13 Sep 2016, at 23:28, Glyph Lefkowitz <gl...@tw...> wrote: > > >> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe <a.h...@gm...> wrote: >> >> But this is the framework (non-apple!) build!… > > "framework build" refers to the way that Python is built. Apple's python, Python.org's python, and Homebrew's python are all framework builds. So, to be clear: this is python.org python? > Doh! Yes, sorry, I think I said this way back in the thread: python.org 2.7.12 (problem doesn’t arise with 3.5.2, also installed). But see this... >> And, again: why isn’t everyone seeing this all the time? (And why didn’t I see it before?) > > There's probably a .pth file somewhere that is stuffing Extras on your sys.path. easy_install (especially older versions) is notorious for creating such things in ways that are hard to inspect for. My usual recommendation at this point is to blow away _everything_ in /Library/Python, ~/Library/Python, ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then reinstall from scratch. (Thanks to SIP you don't need to blow away anything in /System anymore; hooray!) Aha! $ ls -lt /Library/Python/2.7/site-packages/ total 0 -rwxr-xr-x 1 root wheel 157 31 Jul 02:36 Extras.pth* -rw-r--r-- 1 root wheel 119 31 Jul 02:36 README $ more /Library/Python/2.7/site-packages/Extras.pth /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC Now I wonder how those got there?! A > > -glyph |
From: Glyph L. <gl...@tw...> - 2016-09-13 22:28:24
|
> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe <a.h...@gm...> wrote: > > But this is the framework (non-apple!) build!… "framework build" refers to the way that Python is built. Apple's python, Python.org's python, and Homebrew's python are all framework builds. So, to be clear: this is python.org python? > And, again: why isn’t everyone seeing this all the time? (And why didn’t I see it before?) There's probably a .pth file somewhere that is stuffing Extras on your sys.path. easy_install (especially older versions) is notorious for creating such things in ways that are hard to inspect for. My usual recommendation at this point is to blow away _everything_ in /Library/Python, ~/Library/Python, ~/.local/lib/python*, and /Library/Frameworks/Python.framework and then reinstall from scratch. (Thanks to SIP you don't need to blow away anything in /System anymore; hooray!) -glyph |
From: Andrew J. <a.h...@gm...> - 2016-09-13 22:06:00
|
OK, I’m still being dense: > On 13 Sep 2016, at 22:56, Jack Jansen <jac...@cw...> wrote: > > It’s hardcoded in the Python executable, I’m afraid:-( > > Just tried “python -s -S -v”, and the Extras/lib/python is still in sys.path. > > That wasn’t a very smart move by the Apple engineers, I guess…. But this is the framework (non-apple!) build!… And, again: why isn’t everyone seeing this all the time? (And why didn’t I see it before?) > What you could do (but this is getting rather hacky) is create a /Library/Python/2.7/site-packages/removeSystemExtras.pth where you import sys and manually remove the Extras entries. Be careful, putting code (as opposed to pathnames) into a .pth file requires the line to start with “import “. > > Jack > >> On 13-Sep-2016, at 23:37 , Andrew Jaffe <a.h...@gm...> wrote: >> >> Hi, >> >> >>> On 13 Sep 2016, at 22:26, Jack Jansen <jac...@cw...> wrote: >>> >>> You’re absolutely right (both on SIP and on /Library/Frameworks/Python.framework probably being a python.org install), sorry for the confusion. >>> >>> This seems to be due to the way Apple has done the “Extras” directory, and adding things there to sys.path. >>> >>> See for example https://github.com/pypa/pip/issues/2468 >>> >>> If you can get rid of /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in sys.path you should be all set. >> >> Thanks, guys. >> >> Indeed, these /System/Library dirs are in sys.path: >> >> In [1]: import sys >> In [2]: print [p for p in sys.path if 'System' in p] >> ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’] >> >> But I’m still confused: why is this problem only showing up now? Is the same setup that everyone has? Or is it just me for some reason? How and where would sys.path be set to this, and how and where should I change it? (Without disabling SIP, please!) >> >> Andrew >> >> >> >> >> >> >> >>>> On 13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@tw...> wrote: >>>> >>>> >>>>> On Sep 13, 2016, at 12:05 PM, Jack Jansen <Jac...@cw...> wrote: >>>>> >>>>> I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. >>>>> >>>>> Could it be that you’ve installed pyobjc a couple of OSX releases ago? >>>> >>>> This is always worth checking ;). Particularly if it was a few Setuptools releases ago. Also worth checking: ~/Library/Python. >>>> >>>>> And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? >>>> >>>> SIP locks down /System, not /Library. >>>> >>>>> A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. >>>> >>>> This should be an _absolute_ last resort, though. You should be able to clean out /Library just fine. If you have a /Library/Frameworks/Python.framework, that's probably Python.org python, not system python. >>>> >>>> -glyph >>> >>> -- >>> Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack >>> If I can't dance I don't want to be part of your revolution -- Emma Goldman >>> >>> >>> >> > > -- > Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > |
From: Jack J. <jac...@cw...> - 2016-09-13 21:56:14
|
It’s hardcoded in the Python executable, I’m afraid:-( Just tried “python -s -S -v”, and the Extras/lib/python is still in sys.path. That wasn’t a very smart move by the Apple engineers, I guess…. What you could do (but this is getting rather hacky) is create a /Library/Python/2.7/site-packages/removeSystemExtras.pth where you import sys and manually remove the Extras entries. Be careful, putting code (as opposed to pathnames) into a .pth file requires the line to start with “import “. Jack > On 13-Sep-2016, at 23:37 , Andrew Jaffe <a.h...@gm...> wrote: > > Hi, > > >> On 13 Sep 2016, at 22:26, Jack Jansen <jac...@cw...> wrote: >> >> You’re absolutely right (both on SIP and on /Library/Frameworks/Python.framework probably being a python.org install), sorry for the confusion. >> >> This seems to be due to the way Apple has done the “Extras” directory, and adding things there to sys.path. >> >> See for example https://github.com/pypa/pip/issues/2468 >> >> If you can get rid of /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in sys.path you should be all set. > > Thanks, guys. > > Indeed, these /System/Library dirs are in sys.path: > > In [1]: import sys > In [2]: print [p for p in sys.path if 'System' in p] > ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’] > > But I’m still confused: why is this problem only showing up now? Is the same setup that everyone has? Or is it just me for some reason? How and where would sys.path be set to this, and how and where should I change it? (Without disabling SIP, please!) > > Andrew > > > > > > > >>> On 13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@tw...> wrote: >>> >>> >>>> On Sep 13, 2016, at 12:05 PM, Jack Jansen <Jac...@cw...> wrote: >>>> >>>> I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. >>>> >>>> Could it be that you’ve installed pyobjc a couple of OSX releases ago? >>> >>> This is always worth checking ;). Particularly if it was a few Setuptools releases ago. Also worth checking: ~/Library/Python. >>> >>>> And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? >>> >>> SIP locks down /System, not /Library. >>> >>>> A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. >>> >>> This should be an _absolute_ last resort, though. You should be able to clean out /Library just fine. If you have a /Library/Frameworks/Python.framework, that's probably Python.org python, not system python. >>> >>> -glyph >> >> -- >> Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack >> If I can't dance I don't want to be part of your revolution -- Emma Goldman >> >> >> > -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Andrew J. <a.h...@gm...> - 2016-09-13 21:37:50
|
Hi, > On 13 Sep 2016, at 22:26, Jack Jansen <jac...@cw...> wrote: > > You’re absolutely right (both on SIP and on /Library/Frameworks/Python.framework probably being a python.org install), sorry for the confusion. > > This seems to be due to the way Apple has done the “Extras” directory, and adding things there to sys.path. > > See for example https://github.com/pypa/pip/issues/2468 > > If you can get rid of /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in sys.path you should be all set. Thanks, guys. Indeed, these /System/Library dirs are in sys.path: In [1]: import sys In [2]: print [p for p in sys.path if 'System' in p] ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’] But I’m still confused: why is this problem only showing up now? Is the same setup that everyone has? Or is it just me for some reason? How and where would sys.path be set to this, and how and where should I change it? (Without disabling SIP, please!) Andrew >> On 13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@tw...> wrote: >> >> >>> On Sep 13, 2016, at 12:05 PM, Jack Jansen <Jac...@cw...> wrote: >>> >>> I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. >>> >>> Could it be that you’ve installed pyobjc a couple of OSX releases ago? >> >> This is always worth checking ;). Particularly if it was a few Setuptools releases ago. Also worth checking: ~/Library/Python. >> >>> And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? >> >> SIP locks down /System, not /Library. >> >>> A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. >> >> This should be an _absolute_ last resort, though. You should be able to clean out /Library just fine. If you have a /Library/Frameworks/Python.framework, that's probably Python.org python, not system python. >> >> -glyph > > -- > Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > |
From: Jack J. <jac...@cw...> - 2016-09-13 21:26:37
|
You’re absolutely right (both on SIP and on /Library/Frameworks/Python.framework probably being a python.org install), sorry for the confusion. This seems to be due to the way Apple has done the “Extras” directory, and adding things there to sys.path. See for example https://github.com/pypa/pip/issues/2468 If you can get rid of /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in sys.path you should be all set. > On 13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@tw...> wrote: > > >> On Sep 13, 2016, at 12:05 PM, Jack Jansen <Jac...@cw...> wrote: >> >> I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. >> >> Could it be that you’ve installed pyobjc a couple of OSX releases ago? > > This is always worth checking ;). Particularly if it was a few Setuptools releases ago. Also worth checking: ~/Library/Python. > >> And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? > > SIP locks down /System, not /Library. > >> A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. > > This should be an _absolute_ last resort, though. You should be able to clean out /Library just fine. If you have a /Library/Frameworks/Python.framework, that's probably Python.org python, not system python. > > -glyph -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Glyph L. <gl...@tw...> - 2016-09-13 20:59:19
|
> On Sep 13, 2016, at 12:05 PM, Jack Jansen <Jac...@cw...> wrote: > > I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. > > Could it be that you’ve installed pyobjc a couple of OSX releases ago? This is always worth checking ;). Particularly if it was a few Setuptools releases ago. Also worth checking: ~/Library/Python. > And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? SIP locks down /System, not /Library. > A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. This should be an _absolute_ last resort, though. You should be able to clean out /Library just fine. If you have a /Library/Frameworks/Python.framework, that's probably Python.org <http://python.org/> python, not system python. -glyph |
From: Jack J. <jac...@cw...> - 2016-09-13 19:22:08
|
I think /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages is a very old location for storing Python packages. Recently things have been installed in /Library/Python/2.7/site-packages. Could it be that you’ve installed pyobjc a couple of OSX releases ago? And could it be that the OSX upgrade that introduced SIP somehow didn’t clean out user-installed things from /Library/Frameworks before turning off write permission? A possible workaround is to turn off SIP (or boot from the recovery partition), record what is in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages and then clean it out. Then after a reboot re-install the packages you’re still using. Jack > On 13-Sep-2016, at 20:50 , Andrew Jaffe <a.h...@gm...> wrote: > > Dear Chris and Glyph, >> >> On Sunday, September 11, 2016, Andrew Jaffe <a.h...@gm...> wrote: >> Dear Ronald, >> >> Thanks, as usual, for all this. >> >> I have upgraded to the GM version of 10.12 on the beta track. I use the python.org framework builds of python. >> >> When I do "pip list --outdated", I get a long list: > > …. > >> If I do the usual "pip --upgrade" for these, it fails, seemingly because of permissions (Apologies, but I don't have access to the messages anymore): it is clearly trying to delete these versions which seem to live in /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, of course, due to permissions (and system integrity protection). >> >> You can, in fact, do the upgrade with the "--ignore-installed" flag in pip (although there's still a problem with pyobjc-framework-Message). >> >> So: are these errors expected? Is it something in my particular setup? Or the beta program? Is "--ignore-installed" the correct solution? >> >> Thanks, >> >> Andrew >> >>> On 13 Sep 2016, at 16:13, Christopher Barker <pyt...@gm...> wrote: >>> >>> If you are dealing with stuff in /System, then you are dealing with the Ape installed Python, not the Python.org build. >>> >>> It's easy for "pip" and python to get out of sync. >>> >>> Try "which pip" to see which pip you are running. >>> >>> This is why I recommend encoding pip via: >>> >>> python -m pip [args] > > [I tried to comment via the gmane newsgroup version of the lists and my messages never appeared so I hope this works…] > > Just to be clear, I am indeed using the framework pip, which is part of why this is so confusing. In the past, as far as I know, it’s never tried to have anything to do with /System. Again, I don’t know if it’s something about macOS 10.12 Sierra, or my particular setup that is the problem. Also, to be clear, there are no PYTHON* or other environment variables that would affect the python path. Here is a failing session… > > (Aside: I understand that "pyobjc-framework-Message” is actually a bad example: it is the only package that even —-ignore-installed actually fails on, because it has the "--single-version-externally-managed” problem which is a different kettle of fish. But I think the above error message is the same as the one that I would get for any of the other packages in question. Note that pip2 install works fine for packages other than those in my original list.) > > $ command which pip2 > /Library/Frameworks/Python.framework/Versions/2.7/bin/pip2 > > $ pip2 install --upgrade pyobjc-framework-Message > Collecting pyobjc-framework-Message > Using cached pyobjc-framework-Message-3.1.1.tar.gz > Requirement already up-to-date: pyobjc-core>=3.1.1 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from pyobjc-framework-Message) > Requirement already up-to-date: pyobjc-framework-Cocoa>=3.1.1 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from pyobjc-framework-Message) > Installing collected packages: pyobjc-framework-Message > Found existing installation: pyobjc-framework-Message 2.5.1 > Uninstalling pyobjc-framework-Message-2.5.1: > Exception: > Traceback (most recent call last): > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main > status = self.run(options, args) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/commands/install.py", line 317, in run > prefix=options.prefix_path, > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_set.py", line 736, in install > requirement.uninstall(auto_confirm=True) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_install.py", line 742, in uninstall > paths_to_remove.remove(auto_confirm) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_uninstall.py", line 115, in remove > renames(path, new_path) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/utils/__init__.py", line 267, in renames > shutil.move(old, new) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 299, in move > copytree(src, real_dst, symlinks=True) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 208, in copytree > raise Error, errors > Error: [('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message'”)] > > > _______________________________________________ > Pythonmac-SIG maillist - Pyt...@py... > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Andrew J. <a.h...@gm...> - 2016-09-13 18:51:07
|
Dear Chris and Glyph, > > On Sunday, September 11, 2016, Andrew Jaffe <a.h...@gm...> wrote: > Dear Ronald, > > Thanks, as usual, for all this. > > I have upgraded to the GM version of 10.12 on the beta track. I use the python.org framework builds of python. > > When I do "pip list --outdated", I get a long list: …. > If I do the usual "pip --upgrade" for these, it fails, seemingly because of permissions (Apologies, but I don't have access to the messages anymore): it is clearly trying to delete these versions which seem to live in /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, of course, due to permissions (and system integrity protection). > > You can, in fact, do the upgrade with the "--ignore-installed" flag in pip (although there's still a problem with pyobjc-framework-Message). > > So: are these errors expected? Is it something in my particular setup? Or the beta program? Is "--ignore-installed" the correct solution? > > Thanks, > > Andrew > >> On 13 Sep 2016, at 16:13, Christopher Barker <pyt...@gm...> wrote: >> >> If you are dealing with stuff in /System, then you are dealing with the Ape installed Python, not the Python.org build. >> >> It's easy for "pip" and python to get out of sync. >> >> Try "which pip" to see which pip you are running. >> >> This is why I recommend encoding pip via: >> >> python -m pip [args] [I tried to comment via the gmane newsgroup version of the lists and my messages never appeared so I hope this works…] Just to be clear, I am indeed using the framework pip, which is part of why this is so confusing. In the past, as far as I know, it’s never tried to have anything to do with /System. Again, I don’t know if it’s something about macOS 10.12 Sierra, or my particular setup that is the problem. Also, to be clear, there are no PYTHON* or other environment variables that would affect the python path. Here is a failing session… (Aside: I understand that "pyobjc-framework-Message” is actually a bad example: it is the only package that even —-ignore-installed actually fails on, because it has the "--single-version-externally-managed” problem which is a different kettle of fish. But I think the above error message is the same as the one that I would get for any of the other packages in question. Note that pip2 install works fine for packages other than those in my original list.) $ command which pip2 /Library/Frameworks/Python.framework/Versions/2.7/bin/pip2 $ pip2 install --upgrade pyobjc-framework-Message Collecting pyobjc-framework-Message Using cached pyobjc-framework-Message-3.1.1.tar.gz Requirement already up-to-date: pyobjc-core>=3.1.1 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from pyobjc-framework-Message) Requirement already up-to-date: pyobjc-framework-Cocoa>=3.1.1 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from pyobjc-framework-Message) Installing collected packages: pyobjc-framework-Message Found existing installation: pyobjc-framework-Message 2.5.1 Uninstalling pyobjc-framework-Message-2.5.1: Exception: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main status = self.run(options, args) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/commands/install.py", line 317, in run prefix=options.prefix_path, File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_set.py", line 736, in install requirement.uninstall(auto_confirm=True) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_install.py", line 742, in uninstall paths_to_remove.remove(auto_confirm) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_uninstall.py", line 115, in remove renames(path, new_path) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/utils/__init__.py", line 267, in renames shutil.move(old, new) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 299, in move copytree(src, real_dst, symlinks=True) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 208, in copytree raise Error, errors Error: [('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message', '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message', "[Errno 1] Operation not permitted: '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b640000gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message'”)] |
From: Christopher B. <pyt...@gm...> - 2016-09-13 15:13:21
|
If you are dealing with stuff in /System, then you are dealing with the Ape installed Python, not the Python.org build. It's easy for "pip" and python to get out of sync. Try "which pip" to see which pip you are running. This is why I recommend encoding pip via: python -m pip [args] CHB On Sunday, September 11, 2016, Andrew Jaffe <a.h...@gm...> wrote: > Dear Ronald, > > Thanks, as usual, for all this. > > I have upgraded to the GM version of 10.12 on the beta track. I use the > python.org framework builds of python. > > When I do "pip list --outdated", I get a long list: > > altgraph (0.10.2) - Latest: 0.12 [sdist] > macholib (1.5.1) - Latest: 1.7 [sdist] > modulegraph (0.10.4) - Latest: 0.12.1 [sdist] > py2app (0.7.3) - Latest: 0.10 [sdist] > pyobjc-core (2.5.1) - Latest: 3.1.1 [sdist] > pyobjc-framework-Accounts (2.5.1) - Latest: 3.1.1 [sdist] > <a bunch more pyobjc-framework-* (2.5.1) - Latest: 3.1.1 [sdist]> > pyOpenSSL (0.13.1) - Latest: 16.1.0 [wheel] > xattr (0.6.4) - Latest: 0.8.0 [sdist] > > If I do the usual "pip --upgrade" for these, it fails, seemingly because > of permissions (Apologies, but I don't have access to the messages > anymore): it is clearly trying to delete these versions which seem to live > in /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, > of course, due to permissions (and system integrity protection). > > You can, in fact, do the upgrade with the "--ignore-installed" flag in pip > (although there's still a problem with pyobjc-framework-Message). > > So: are these errors expected? Is it something in my particular setup? Or > the beta program? Is "--ignore-installed" the correct solution? > > Thanks, > > Andrew > > p.s. none of these issues arise with Python3/pip3, of course. > > On 22/07/2016 14:46, Ronald Oussoren wrote: > >> Hi, >> >> I’m slowly working my way through the SDK headers for macOS 10.12 during >> idle time at EuroPython2016, from the frameworks with small diffs to those >> with larger diffs. >> >> There are at the moment about 26 frameworks I haven’t looked at at all, >> and another 10 where I know I have to do some more work. The rest should >> have up to date metadata on my machine, but haven’t been tested on macOS >> 10.12 yet (and that won’t change until I get around to actually installing >> a VM running 10.12). >> >> All of this was done using the headers in the Xcode 8 beta 2, I haven’t >> looked at the incremental changes to the SDK in beta 3 yet (and likely >> won’t until I have made a pass through all frameworks). That said, the >> diffs from beta 2 to later beta’s and the final release should be fairly >> small (he wrote hopefully). >> >> What needs to be done to get proper support for 10.12: >> >> * Finish updating the metadata. I suspect that this is a couple of days >> work, I have worked may way through the diffs of a fairly large number of >> frameworks, but haven’t looked at the more complicated ones yet (such as >> Foundation and AppKit). Also, a fairly large subset of the frameworks I >> have looked at didn’t have any significant updates compared to 10.11 (but >> some of them still had large textual diffs due to restructuring of header >> files). >> >> * Install a 10.12 VM and run tests there. This will likely result in more >> work, there’s already a pull request about NSSecureCoder warnings on 10.12 >> that needs looking into and there’s bound to be more issues. >> >> * Do the build and test dance on older OSX releases. >> The annoying bit for that: there’s a know issue with building on OSX >> 10.7, see issue #100. I haven’t been able to look into that yet >> because I don’t have an VM with 10.7 on my laptop and haven’t been >> able to install 10.7 there yet. I probably have such a VM on >> an external disk somewhere, but I’m not sure about that. >> >> When all that is done I can do a release that includes 10.12 support, >> with some luck around the time of the 10.12 release itself. I’ll definitely >> push the metadata updates to bitbucket once I’ve finished looking through >> the 10.12 SDK diffs. >> >> In the longer run I want to provide wheels for PyObjC, but that requires >> more work. In particular, I only want to do that after automating more of >> the release work because I’ve noticed that I’m already postponing doing new >> releases due to the amount of work and don’t want to make things worse in >> that regard. >> >> BTW. I’ll likely won’t work on metadata updates during the EP2016 >> sprints, my current plan is to keep the tradition of working on PEP 447 >> alive and try to actually get it accepted this year. >> >> Ronald >> >> PS. “A couple of days work” probably means that it will take me several >> calendar weeks to actually finish the work because I have limited time to >> work on this and don’t want to spent all that time on this rather tedious >> work. >> >> [#100]: https://bitbucket.org/ronaldoussoren/pyobjc/issues/100/ >> cannot-find-interface-declaration-for >> ------------------------------------------------------------ >> ------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning >> reports.http://sdm.link/zohodev2dev >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >> >> > > _______________________________________________ > Pythonmac-SIG maillist - Pyt...@py... > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython |
From: Andrew J. <a.h...@gm...> - 2016-09-12 08:58:57
|
[Apologies if more than one copy of this message is posted!] On 11/09/2016 20:57, Glyph Lefkowitz wrote: > >> On Sep 11, 2016, at 3:12 AM, Andrew Jaffe <a.h...@gm... >> <mailto:a.h...@gm...>> wrote: >> >> If I do the usual "pip --upgrade" for these, it fails, seemingly >> because of permissions (Apologies, but I don't have access to the >> messages anymore): it is clearly trying to delete these versions which >> seem to live in >> /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, >> of course, due to permissions (and system integrity protection). > > This is expected, and desired, even. Don't install packages into your > system Python. Make a virtualenv and install pyobjc there, or do a `pip > install --user`. That should work fine. Sorry if I'm not being clear. I'm using python.org framework python, which supplies its own pip, and its own location for packages: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages In the past, upgrades have never been a problem, so I don't know if anything has changed with the latest macOS, or the latest pyobjc, or the latest python build, or... And I don't know if the "--ignore-installed" solution is a workaround, or actually the right answer. (I do know about virtualenv, but I don't think that's the route I want to go at this point, and I'm pretty sure I shouldn't have to.) Yours, Andrew |
From: Andrew J. <a.h...@gm...> - 2016-09-11 22:58:50
|
On 11/09/2016 20:57, Glyph Lefkowitz wrote: > >> On Sep 11, 2016, at 3:12 AM, Andrew Jaffe <a.h...@gm... >> <mailto:a.h...@gm...>> wrote: >> >> If I do the usual "pip --upgrade" for these, it fails, seemingly >> because of permissions (Apologies, but I don't have access to the >> messages anymore): it is clearly trying to delete these versions which >> seem to live in >> /System/Library/Frameworks/Python.framework/Versions/2.7/. This fails, >> of course, due to permissions (and system integrity protection). > > This is expected, and desired, even. Don't install packages into your > system Python. Make a virtualenv and install pyobjc there, or do a `pip > install --user`. That should work fine. Hi, sorry if I wasn't clear -- this is a python.org install, and the pip I'm running comes from that. It shouldn't try to change the system-installed packages; it never has in the past, and that's why this behavior seems strange. |