On 31 Oct, 2013, at 17:49, Daniel Holth <[email protected]> wrote: > On Thu, Oct 31, 2013 at 10:26 AM, Nick Coghlan <[email protected]> wrote: >> On 31 October 2013 23:38, Ronald Oussoren <[email protected]> wrote: >>> >>> On 21 Oct, 2013, at 20:52, Donald Stufft <[email protected]> wrote: >>> >>>> >>>> On Oct 21, 2013, at 1:02 PM, Chris Barker <[email protected]> wrote: >>>> >>>>> On Fri, Oct 18, 2013 at 6:22 PM, Nick Coghlan <[email protected]> wrote: >>>>>>> -- it would be very useful if folks could easily >>>>>>> get binary wheels for OS-X >>>>>> >>>>>> We do plan to support it, but the pip devs uncovered a hole in the >>>>>> current >>>>>> wheel spec that means it generates the same filename on *nix systems for >>>>>> wheels that need to have different names for the download side of things >>>>>> to >>>>>> work properly >>>>> >>>>> THanks -- but really? don't OS-X wheels get: >>>>> >>>>> macosx_10_6_intel >>>>> >>>>> or some such tacked on? Where does that go wrong? >>>> >>>> Homebrew, Mac Ports, Fink. That would work OK if nobody ever installed >>>> things >>>> that the system didn't provide. >>> >>> I don't understand this, what would break? Binary wheels that reference >>> shared libraries that aren't included in the wheel (or a default system >>> install) won't work, but that's also true on Windows. >> >> The main difference I see is that on Windows, the ABI for the >> *CPython* shared library is significantly less likely to vary across >> machines. >> >> By contrast, it's relatively easy to change the ABI on *nix systems, >> as it depends on what you pass as configure options. > > On OS X I would hope you are uploading only wheels built with > python.org-Python but maybe you aren't, everyone has their > preferences.
And that shouldn't be a problem, the various builds of Python on OSX should be compatible if the have the same platform tag in the wheel filename. Well, barring idiocy like installing a completely different libc, that might cause problems because (at least for 2.7) some libc types leak into the CPython ABI. But anyway, I'd love to use binary wheels in the future to distribute prebuilt binaries for some of my projects and that's why I reacted on a message that mentioned that binary installs aren't supported yet. If I don't understand what the issue is I can't try to help finding I solution :-) Is it "just" a matter of researching if the various build options on OSX really lead to binaries with the same ABI, or is more work needed? Ronald > >> Will a C extension built with Homebrew Python work with the Python Mac >> OS X installer from python.org? Probably, but given how painful ABI >> mismatches with shared libraries can be to debug, "probably" doesn't >> cut it until someone has the chance to thoroughly review the potential >> for problems. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
