From chris.barker at noaa.gov Thu Mar 6 23:29:53 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Thu, 6 Mar 2014 14:29:53 -0800 Subject: [Pythonmac-SIG] linking extensions for older builds with newer pythons... Message-ID: The numpy folks are trying hard to get binary wheel sup on PyPi yeah! But this brought hup an issue -- PyPI policy is that binary wheels should be built for the python.org binaries -- which is great. The Python.org binaries are built for >=10.6, 32+64 bit Intel, and have the platfrom name: 10_6_intel All is well and good. The complication: The Apple builds of Python presumably use the newer SDKs, and have platform names like: 10_7_intel the 10_7 does not match the 10_6, and thus pip will not install the binary. If you re-name the wheel, then pip happily installs it, and it seems to work fine. So there is a pull request for a patch to the tools to support >=10_6, rather than =10_6 -- so that packages built python.org build will also be installable on newer builds. This has worked for years with numpy and others (and now that I think about it, wxPython has binaries that work on python.org and Apple's build.) So is it officially supported to link a *.so built against a older SDK to a application buit with a newer SDK? If so ,then this seems a nice convenience for the MAc crowd. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at acm.org Fri Mar 7 01:38:59 2014 From: nad at acm.org (Ned Deily) Date: Thu, 06 Mar 2014 16:38:59 -0800 Subject: [Pythonmac-SIG] linking extensions for older builds with newer pythons... References: Message-ID: In article , Chris Barker wrote: > The numpy folks are trying hard to get binary wheel sup on PyPi yeah! > > But this brought hup an issue -- PyPI policy is that binary wheels should > be built for the python.org binaries -- which is great. [...] > So is it officially supported to link a *.so built against a older SDK to a > application buit with a newer SDK? If so ,then this seems a > nice convenience for the MAc crowd. I've just commented on this in more detail on the pip issue tracker: https://github.com/pypa/pip/pip/pull/1465 The short answer is that there are at least two issues here: older SDK vs newer SDK and python.org Python vs Apple-supplied system Python. In general, we don't officially test these combinations nor claim to support them but, for many cases, they do seem to work OK, modulo some known potential gotchas (like mixing C++ runtimes on 10.9). We do specifically support that current python.org Pythons built on 10.6 work on 10.6 through 10.9 and that it is possible to build C extensions on any of them that will work on at least that installed OS X version. In other words, if you want to build a C extension module that works with 10.6 through 10.9, the safest approach is to use the 10.6 SDK. If you only need it to work on your current system, the installed system headers should be OK, which Distutils falls back to if the SDK is not available in its traditional location. -- Ned Deily, nad at acm.org From nad at acm.org Fri Mar 7 01:49:12 2014 From: nad at acm.org (Ned Deily) Date: Thu, 06 Mar 2014 16:49:12 -0800 Subject: [Pythonmac-SIG] linking extensions for older builds with newer pythons... References: Message-ID: In article , Ned Deily wrote: [...] > I've just commented on this in more detail on the pip issue tracker: > > https://github.com/pypa/pip/pip/pull/1465 er, https://github.com/pypa/pip/pull/1465 -- Ned Deily, nad at acm.org From ronaldoussoren at mac.com Fri Mar 7 15:17:50 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 07 Mar 2014 15:17:50 +0100 Subject: [Pythonmac-SIG] linking extensions for older builds with newer pythons... In-Reply-To: References: Message-ID: On 07 Mar 2014, at 01:38, Ned Deily wrote: > In article > , > Chris Barker wrote: > >> The numpy folks are trying hard to get binary wheel sup on PyPi yeah! >> >> But this brought hup an issue -- PyPI policy is that binary wheels should >> be built for the python.org binaries -- which is great. > [...] >> So is it officially supported to link a *.so built against a older SDK to a >> application buit with a newer SDK? If so ,then this seems a >> nice convenience for the MAc crowd. > > I've just commented on this in more detail on the pip issue tracker: > > https://github.com/pypa/pip/pip/pull/1465 > > The short answer is that there are at least two issues here: older SDK > vs newer SDK and python.org Python vs Apple-supplied system Python. In > general, we don't officially test these combinations nor claim to > support them but, for many cases, they do seem to work OK, modulo some > known potential gotchas (like mixing C++ runtimes on 10.9). We do > specifically support that current python.org Pythons built on 10.6 work > on 10.6 through 10.9 and that it is possible to build C extensions on > any of them that will work on at least that installed OS X version. In > other words, if you want to build a C extension module that works with > 10.6 through 10.9, the safest approach is to use the 10.6 SDK. If you > only need it to work on your current system, the installed system > headers should be OK, which Distutils falls back to if the SDK is not > available in its traditional location. But note that it is not necessary to use the 10.6 SDK, it is just slightly safer and in particular when using a build system that does autoconfiguration based on compile/link checks: that could find newly introduced symbols that are present in the latest SDK, but not on the older system. Another potential problem is linking to system shared libraries that aren?t Apple proprietary, such as openssl. When using a newer SDK you?ll generally link with the newest version of those shared libraries that are included in the newer system and those might not be available on older systems. The workaround for that is to not link to those libraries at all. This generally isn?t a problem for Apple libraries (such as the frameworks or libSystem) because there the name of the shared library doesn?t change between OSX releases. In general I?d be fine with: * PIP accepting a wheel with deployment target 10.6 on a Python with deployment target 10.9 * PIP accepting a wheel with more architectures than supported by the Python build (e.g. a wheel with ?intel? on a x86_64 only build) That should be generally safe, with the exceptions listed above. It could be nice to have options for alternatives as well, but those should be optional and not enabled by default because they break some use cases (such as building an application on a new machine and deploying it on an older machine): * PIP accepting a wheel with a deployment target <= the currently running OSX version (e.g. install a 10.8 wheel on a machine running OSX 10.9, irrespective of the deployment target for the Python interpreter) * PIP accepting any wheel that contains the CPU architecture for the currently running architecture (e.g. installing a x86_64 only wheel on an ?intel? Python installation when running on a newish machine) Ronald > > -- > Ned Deily, > nad at acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From mk0423 at towb.de Sun Mar 16 18:26:23 2014 From: mk0423 at towb.de (mk0423 at towb.de) Date: Sun, 16 Mar 2014 18:26:23 +0100 Subject: [Pythonmac-SIG] webbrowser uses osascript instead of open Message-ID: <29C220C0-E1C7-4CB3-9A03-42D19B657D31@towb.de> Hi, why does the webbrowser module use bin/osascript instead of bin/open? Seems more complicated, and both support launching browsers other than the default. From nad at acm.org Sun Mar 16 22:16:12 2014 From: nad at acm.org (Ned Deily) Date: Sun, 16 Mar 2014 14:16:12 -0700 Subject: [Pythonmac-SIG] webbrowser uses osascript instead of open References: <29C220C0-E1C7-4CB3-9A03-42D19B657D31@towb.de> Message-ID: In article <29C220C0-E1C7-4CB3-9A03-42D19B657D31 at towb.de>, mk0423 at towb.de wrote: > why does the webbrowser module use bin/osascript instead of bin/open? Seems > more complicated, and both support launching browsers other than the default. There's probably not a good reason other than the existing code dates back to the early days of OS X (circa 2002) and it gets very little attention these days. Feel free to submit a patch (with tests) to the bug tracker if its behavior can be improved. -- Ned Deily, nad at acm.org From matthew.brett at gmail.com Tue Mar 25 23:55:29 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 25 Mar 2014 15:55:29 -0700 Subject: [Pythonmac-SIG] Utility to copy dynamic libs into OSX wheels Message-ID: Hi, I just released a first very alpha version of a utility called 'delocate'. It analyzes code in a wheel for any missing dynamic libraries, and copies these into the wheel: https://pypi.python.org/pypi/delocate For example, something like: delocate-wheel scipy-0.14.0b1-cp34-cp34m-macosx_10_6_intel.whl will find the non-system dynamic libs that the wheel needs, and copy them into the wheel, fixing the links as it goes. This can make it easier to release wheels that will work across machines. I'd be very grateful for feedback... Cheers, Matthew From ronaldoussoren at mac.com Wed Mar 26 14:10:11 2014 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 26 Mar 2014 13:10:11 +0000 (GMT) Subject: [Pythonmac-SIG] Utility to copy dynamic libs into OSX wheels In-Reply-To: Message-ID: <7213020d-b6df-4eee-bcd7-d9b4ac449e28@me.com> On Mar 25, 2014, at 11:55 PM, Matthew Brett wrote: Hi, I just released a first very alpha version of a utility called 'delocate'. It analyzes code in a wheel for any missing dynamic libraries, and copies these into the wheel: https://pypi.python.org/pypi/delocate For example, something like: delocate-wheel scipy-0.14.0b1-cp34-cp34m-macosx_10_6_intel.whl will find the non-system dynamic libs that the wheel needs, and copy them into the wheel, fixing the links as it goes. This can make it easier to release wheels that will work across machines. I'd be very grateful for feedback... ? Looks interesting. Have you considered using macholib to change the macho headers? Ronald Cheers, Matthew _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: