Thread: Re: [Pyobjc-dev] [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra) (Page 2)
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
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-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: 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-12 06:08:31
|
> On Oct 11, 2016, at 2:26 PM, Ronald Oussoren <ron...@ma...> wrote: > > 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. Ever since the introduction of SIP, system-level debugging tools like LLDB have worked very poorly for me, even on self-built executables. I don't see a difference in its behavior on 10.11 vs. 10.12 though. I can run it on `curl` from Homebrew, but not `python`; my guess being that Python is trying to dlopen() some SIP-protected thing whereas `curl` is loading only things from Homebrew? If it's a VM, then system integrity is less of a concern; have you tried just blanket disabling SIP to see if that improves the situation? I've had some luck with other tools (dtrace, mostly) working in that configuration. (I had to totally disable SIP though, disabling one flag at a time didn't work.) -glyph |
|
From: Andrew J. <a.h...@gm...> - 2016-10-12 18:49:53
|
On 11/10/2016 22:26, Ronald Oussoren wrote: > >> On 17 Sep 2016, at 19:59, Glyph Lefkowitz <gl...@tw... >> <mailto:gl...@tw...>> wrote: >> >>> >>> On Sep 17, 2016, at 9:27 AM, Ned Deily <na...@py... >>> <mailto: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...> >>>>> <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. Not me. If I understand correctly, Glyph -- who undoubtedly understand the situation better than I do -- still thinks that there's no actual bug here, since we shouldn't be using the framework build this way, but I'm not sure I understand/agree... > 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 ;-) Andrew |
|
From: Glyph L. <gl...@tw...> - 2016-10-12 19:09:51
|
> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe <a.h...@gm...> wrote: > > Not me. If I understand correctly, Glyph -- who undoubtedly understand the situation better than I do -- still thinks that there's no actual bug here, since we shouldn't be using the framework build this way, but I'm not sure I understand/agree... To be honest, I'm not 100% sure this is a good idea either; it's just that I know Donald Stufft has had a terrible time with Apple system python for several years, and he regards this as a positive change. From my personal perspective, there's a good case to be made that a python in /System should just load from /System and one in /Library should load only from /Library, similar to the way --prefix works on "regular" UNIX. But, this is what we've got :). -glyph |
|
From: Andrew J. <a.h...@gm...> - 2016-09-11 10:15:18
|
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 > |
|
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-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: Ronald O. <ron...@ma...> - 2016-10-12 20:02:25
|
> On 12 Oct 2016, at 21:09, Glyph Lefkowitz <gl...@tw...> wrote: > > >> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe <a.h...@gm... <mailto:a.h...@gm...>> wrote: >> >> Not me. If I understand correctly, Glyph -- who undoubtedly understand the situation better than I do -- still thinks that there's no actual bug here, since we shouldn't be using the framework build this way, but I'm not sure I understand/agree... > > To be honest, I'm not 100% sure this is a good idea either; it's just that I know Donald Stufft has had a terrible time with Apple system python for several years, and he regards this as a positive change. From my personal perspective, there's a good case to be made that a python in /System should just load from /System and one in /Library should load only from /Library, similar to the way --prefix works on "regular" UNIX. But, this is what we've got :). I don’t mind if the /System python looks in /Library for stuff that the user installed there, but I do consider it a bug that Apple installs system files in /Library because that affects all installations of Python 2.7. That’s what we get for playing nice with OSX conventions for where to locate files :-(. Luckily this isn’t a problem for Python3 as Apple doesn’t ship that (and I’d be surprised if they ever unless they start shipping Python3 code as part of the OS). Ronald > > -glyph > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
|
From: Andrew J. <a.h...@gm...> - 2016-10-25 08:37:03
|
On 12/10/2016 21:02, Ronald Oussoren wrote: > >> On 12 Oct 2016, at 21:09, Glyph Lefkowitz <gl...@tw... >> <mailto:gl...@tw...>> wrote: >> >>> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe <a.h...@gm... >>> <mailto:a.h...@gm...>> wrote: >>> >>> Not me. If I understand correctly, Glyph -- who undoubtedly >>> understand the situation better than I do -- still thinks that >>> there's no actual bug here, since we shouldn't be using the framework >>> build this way, but I'm not sure I understand/agree... >> >> To be honest, I'm not 100% sure this is a good idea either; it's just >> that I know Donald Stufft has had a terrible time with Apple system >> python for several years, and he regards this as a positive change. >> From my personal perspective, there's a good case to be made that a >> python in /System should just load from /System and one in /Library >> should load only from /Library, similar to the way --prefix works on >> "regular" UNIX. But, this is what we've got :). > > I don’t mind if the /System python looks in /Library for stuff that the > user installed there, but I do consider it a bug that Apple installs > system files in /Library because that affects all installations of > Python 2.7. > > That’s what we get for playing nice with OSX conventions for where to > locate files :-(. Luckily this isn’t a problem for Python3 as Apple > doesn’t ship that (and I’d be surprised if they ever unless they start > shipping Python3 code as part of the OS). Well, I did submit a radar, and although I'm not sure how far the NDA extends, I hope I can say that, unfortunately, I got a "behaves as intended" response... Andrew |
|
From: Ronald O. <ron...@ma...> - 2016-10-12 20:15:24
|
> On 12 Oct 2016, at 08:08, Glyph Lefkowitz <gl...@tw...> wrote:
>
>
>> On Oct 11, 2016, at 2:26 PM, Ronald Oussoren <ron...@ma... <mailto:ron...@ma...>> wrote:
>>
>> 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.
>
> Ever since the introduction of SIP, system-level debugging tools like LLDB have worked very poorly for me, even on self-built executables. I don't see a difference in its behavior on 10.11 vs. 10.12 though. I can run it on `curl` from Homebrew, but not `python`; my guess being that Python is trying to dlopen() some SIP-protected thing whereas `curl` is loading only things from Homebrew?
>
> If it's a VM, then system integrity is less of a concern; have you tried just blanket disabling SIP to see if that improves the situation? I've had some luck with other tools (dtrace, mostly) working in that configuration. (I had to totally disable SIP though, disabling one flag at a time didn't work.)
I haven’t had problems with SIP on 10.11. This also doesn’t seem to be a SIP issue, I got the same behavior after disabling SIP.
I did manage to debug on the VM’s console by explicitly running the Python interpreter inside the framework (Python.app/Contents/MacOS/Python) instead of the launcher in {sys.prefix}/bin. This doesn’t work in an SSH session though. That’s a bit annoying, but is workable until I get around to installing sierra on my main machine.
Ronald
P.S. I’m debugging using a Python.org <http://python.org/> install of python3.5, not using the /System installation of Python2.7. Using the latter is asking for problems when working on a package that Apple also ships.
>
> -glyph
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
|
|
From: Ronald O. <ron...@ma...> - 2016-10-25 19:39:01
|
> On 25 Oct 2016, at 10:36, Andrew Jaffe <a.h...@gm...> wrote: > > On 12/10/2016 21:02, Ronald Oussoren wrote: > > > >> On 12 Oct 2016, at 21:09, Glyph Lefkowitz <gl...@tw... > >> <mailto:gl...@tw...>> wrote: > >> > >>> On Oct 12, 2016, at 11:49 AM, Andrew Jaffe <a.h...@gm... > >>> <mailto:a.h...@gm...>> wrote: > >>> > >>> Not me. If I understand correctly, Glyph -- who undoubtedly > >>> understand the situation better than I do -- still thinks that > >>> there's no actual bug here, since we shouldn't be using the framework > >>> build this way, but I'm not sure I understand/agree... > >> > >> To be honest, I'm not 100% sure this is a good idea either; it's just > >> that I know Donald Stufft has had a terrible time with Apple system > >> python for several years, and he regards this as a positive change. > >> From my personal perspective, there's a good case to be made that a > >> python in /System should just load from /System and one in /Library > >> should load only from /Library, similar to the way --prefix works on > >> "regular" UNIX. But, this is what we've got :). > > > > I don’t mind if the /System python looks in /Library for stuff that the > > user installed there, but I do consider it a bug that Apple installs > > system files in /Library because that affects all installations of > > Python 2.7. > > > > That’s what we get for playing nice with OSX conventions for where to > > locate files :-(. Luckily this isn’t a problem for Python3 as Apple > > doesn’t ship that (and I’d be surprised if they ever unless they start > > shipping Python3 code as part of the OS). > > Well, I did submit a radar, and although I'm not sure how far the NDA extends, I hope I can say that, unfortunately, I got a "behaves as intended" response… That’s too bad. But I wouldn’t expect this to change anytime soon even if this would have been classified as a bug. Ronald |
|
From: Ronald O. <ron...@me...> - 2016-12-13 12:20:27
|
> On 14 Sep 2016, at 00:28, Glyph Lefkowitz <gl...@tw...> wrote: > > >> On Sep 13, 2016, at 3:05 PM, Andrew Jaffe <a.h...@gm... <mailto: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 <http://python.org/>'s python, and Homebrew's python are all framework builds. So, to be clear: this is python.org <http://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!) It should be enough to remove “/Library/Python” from the list of site packages in the non-system install of Python, it is added at the end of setsitepackages() in site.py. This should be done before running any code (particularly the ensurepip tool). That would remove the directory containing the Extras.pth on 10.12, and hence remove the conflict between Apple stuff and user provided stuff. Doing this with the python.org installer requires some care, as it will by default run ensurepip during the installation (but this can be turned off). According to issue 28440 /Library/Python/2.7/site-packages will no longer be treated as a site-packages directory in a future release of 2.7. Ronald > -glyph > _______________________________________________ > Pythonmac-SIG maillist - Pyt...@py... > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG |
|
From: Christopher B. <pyt...@gm...> - 2016-12-13 16:37:37
|
Personally, I have avoided all this mess the last couple years by using conda (miniconda install). It does a nice job of keeping entirely separate from the system ( or any other) python, and it can manage non-python libs as well, so you don't need Brew. And it has environments that are like virtualenv, but with the C libs isolated as well. Between the default channel, conda-forge, and pip for pure python packages, there is a lot available. If we were to add s PyObjC build to conda-forge, the full stack should "just work". And conda forge has s CI system set up to auto build for various python versions.... http://conda-forge.github.io/#add_recipe - CHB > >>>>>> 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 > > _______________________________________________ > > Pythonmac-SIG maillist - Pyt...@py... > > https://mail.python.org/mailman/listinfo/pythonmac-sig > > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG > > |
|
From: Glyph L. <gl...@tw...> - 2016-12-13 19:16:27
|
> On Dec 13, 2016, at 8:37 AM, Christopher Barker <pyt...@gm...> wrote: > > Personally, I have avoided all this mess the last couple years by using conda (miniconda install). It does a nice job of keeping entirely separate from the system ( or any other) python, and it can manage non-python libs as well, so you don't need Brew. And it has environments that are like virtualenv, but with the C libs isolated as well. > > Between the default channel, conda-forge, and pip for pure python packages, there is a lot available. > > If we were to add s PyObjC build to conda-forge, the full stack should "just work". > > And conda forge has s CI system set up to auto build for various python versions.... > > http://conda-forge.github.io/#add_recipe <http://conda-forge.github.io/#add_recipe> Why would this be necessary? Can't conda just install the wheels from PyPI? -glyph |
|
From: Chris B. <chr...@no...> - 2016-12-14 17:45:24
|
On Tue, Dec 13, 2016 at 11:16 AM, Glyph Lefkowitz <gl...@tw...> wrote: > If we were to add s PyObjC build to conda-forge, the full stack should > "just work". > > And conda forge has s CI system set up to auto build for various python > versions.... > > http://conda-forge.github.io/#add_recipe > > > Why would this be necessary? Can't conda just install the wheels from > PyPI? > Well, maybe -- conda has grown better support for pip lately, so it may work OK. Back in the day, mixing conda and pipi got ugly fast, so I far prefer to make a native conda package for everything. conda also has a non-framework build of Python -- not sure if that would cause any issues with the wheels. -CHB -- 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 Chr...@no... |
|
From: Glyph L. <gl...@tw...> - 2016-12-15 01:33:08
|
> On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no...> wrote: > > conda also has a non-framework build of Python -- not sure if that would cause any issues with the wheels. I am not up on all the technical specifics, but this suggests to me that Conda would be generally unsuitable for use as a Mac native development environment, and hence not a Python you'd want to use pyobjc with. If you don't have a framework build, you don't have an app bundle; if you don't have an app bundle then many frameworks will fail to initialize, or will start behaving in bizarre ways. APIs like NSUserNotificationCenter will just silently do nothing, CoreLocation won't respond... it's always very confusing and hard to troubleshoot. That said, I don't think the framework/non-framework-ness of the build is relevant to the ABI; the wheels should work fine just from a "will they link and run" perspective. And many CoreFoundation APIs definitely work without an app bundle, so, not completely useless :-). -glyph |
|
From: Christopher B. <pyt...@gm...> - 2016-12-15 06:25:43
|
On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <gl...@tw...> wrote: > > On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no...> wrote: > > conda also has a non-framework build of Python -- not sure if that would > cause any issues with the wheels. > > > I am not up on all the technical specifics, but this suggests to me that > Conda would be generally unsuitable for use as a Mac native development > environment, and hence not a Python you'd want to use pyobjc with. > > If you don't have a framework build, you don't have an app bundle; > in the standard python.org builds, the Framework Build provides an app bundle. But having python in a Framework is completely orthogonal to the App BUndle issue. Yes, you need the executable to be in an app bundle in order to access the Window manager (and who knows what else), but again, that has nothign to do with the Framework Build. unfortunately, the build scripts only have a couple ready-to-go options, so to get the app bundle executable, you do need the Framework build. I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's no good reason for a Framework build at all -- it just seemed like the Apple-y way to do it at the time, and now we have the legacy. However, conda has supplied an app bundle version, which you can install with: conda install python.app it supplies a "pythonw" script that bootstraps s python inside a app bundle and can run GUI apps -- I know it works fine with wxPython, for instance. Having to use pythonw is a kind of a pain -- and the ned for it was removed years ago in the Framework builds -- those builds leverage a small executable that bootstraps into an app bundle -- and works fine as a "regular" python interpreter as well. There's no reason we couldn't build that same executable outside a framework -- someone just need to figure out the build scripts -- which i was hoping to do last PyCon, but you can only get so much done in a 1-1/2 days of sprinting -- plus I'm no build script expert. At All. Anyway, it should be easy to see how well the new wheels work with conda -- and/or make a conda recipe -- maybe I'll get to it soon. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython |
|
From: Ronald O. <ron...@ma...> - 2016-12-15 08:59:22
|
> On 15 Dec 2016, at 07:25, Christopher Barker <pyt...@gm...> wrote: > > On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <gl...@tw... <mailto:gl...@tw...>> wrote: > >> On Dec 14, 2016, at 9:44 AM, Chris Barker <chr...@no... <mailto:chr...@no...>> wrote: >> >> conda also has a non-framework build of Python -- not sure if that would cause any issues with the wheels. > > I am not up on all the technical specifics, but this suggests to me that Conda would be generally unsuitable for use as a Mac native development environment, and hence not a Python you'd want to use pyobjc with. > > If you don't have a framework build, you don't have an app bundle; > > in the standard python.org <http://python.org/> builds, the Framework Build provides an app bundle. But having python in a Framework is completely orthogonal to the App BUndle issue. > > Yes, you need the executable to be in an app bundle in order to access the Window manager (and who knows what else), but again, that has nothign to do with the Framework Build. > > unfortunately, the build scripts only have a couple ready-to-go options, so to get the app bundle executable, you do need the Framework build. > > I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's no good reason for a Framework build at all -- it just seemed like the Apple-y way to do it at the time, and now we have the legacy. IIRC the framework build was initially created for NextStep, and was updated for Mac OS X when that came out (and later tweaked to support fat binaries). A framework was the right way to integrate into the OS at the time, and IMHO still is a good choice w.r.t. platform integration. Frameworks have the nice feature that everything related to the framework is stored in a single location, with proscribed location for that location. This is especially useful when doing side-by-side installation of Python 2 and Python 3, those naturally get different locations for their binaries which avoids conflicts when installing scripts into both of them. > > > However, conda has supplied an app bundle version, which you can install with: > > conda install python.app > > it supplies a "pythonw" script that bootstraps s python inside a app bundle and can run GUI apps -- I know it works fine with wxPython, for instance. > > Having to use pythonw is a kind of a pain -- and the ned for it was removed years ago in the Framework builds -- those builds leverage a small executable that bootstraps into an app bundle -- and works fine as a "regular" python interpreter as well. > > There's no reason we couldn't build that same executable outside a framework -- someone just need to figure out the build scripts -- which i was hoping to do last PyCon, but you can only get so much done in a 1-1/2 days of sprinting -- plus I'm no build script expert. At All. Building python.app + the launcher script outside of a framework should be easy, but I don’t understand why you’d want to do so as this will give you yet another way to deploy python on macOS. BTW. In the longer run I’d love to see a binary distribution that’s just a Python.app with everything bundled inside, that would reduce the friction of installing python even further. The main launcher of the app bundle could be a launcher for IDLE, possibly enhanced with a menu for installing symlinks to bundled executables/scripts into /usr/local/bin. Sadly enough distribution through the Mac Appstore isn’t really an option for this, the sandboxing requirements aren’t suitable for an IDE (as any script launched from the sandboxed IDE is also subjected to the sandbox restrictions, which isn’t very nice for users). To get back on topic, PyObjC’s wheels should work fine with conda assuming it follows the platform defaults w.r.t. the size of unicode characters (for Python 2.7). I don’t test with conda though. Ronald |
|
From: Cosimo L. <cos...@da...> - 2016-12-15 21:08:00
|
+1 on having the official Python.org distribution be a standalone Python.app that users could just drag-and-drop like with the rest of native non-AppStore apps! (I wish Apple shipped macOS with Python 3...) And thanks a lot Ronald for the PyObjC wheels on PyPi :D Cheers -- Cosimo Lupo |
|
From: Ronald O. <ron...@ma...> - 2016-12-16 09:07:50
|
> On 15 Dec 2016, at 21:41, Cosimo Lupo <cos...@da...> wrote: > > +1 on having the official Python.org distribution be a standalone Python.app that users could just drag-and-drop like with the rest of native non-AppStore apps! A Python.app from python.org <http://python.org/> should be a long term plan at best, it would be better to start work on this outside of constraints of CPython (e.g. not being able to use libraries outside of the stdlib and only shipping feature updates with major releases). > > (I wish Apple shipped macOS with Python 3…) I’ve mixed feelings about that, on the one hand having Python 3 available by default would be cool, but on the other hand you’d have to rely on Apple to keep that software up to date and Apple tends to only ship security updates between major releases. That’s not too bad for Python 2.7, but is less useful for 3.x. > > And thanks a lot Ronald for the PyObjC wheels on PyPi :D That turned out to be a lot less work than I expected, I should have done the work a long time ago ;-) Ronald |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X