<p dir="ltr"><br>
On 23 Oct 2013 05:42, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
><br>
> On Mon, Oct 21, 2013 at 11:52 AM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> >> Thanks -- but really? don't OS-X wheels get:<br>
> >><br>
> >> macosx_10_6_intel<br>
> >><br>
> >> or some such tacked on? Where does that go wrong?<br>
> ><br>
> > Homebrew, Mac Ports, Fink. That would work OK if nobody ever installed things<br>
> > that the system didn't provide.<br>
><br>
> OK -- yes, that will NEVER work. It's worse than the Linux situation.<br>
><br>
> But then, it's the same everywhere -- if someone builds a binary wheel<br>
> for Windows that depends on some non-standard dll, or is built against<br>
> a weirdly custom-built Python, it won't work either.<br>
><br>
> It's been more or less a consensus in the python-mac community that we<br>
> seek to provide binaries for the Python.org pythons, and that they<br>
> shouldn't depend on non-standard external libs -- just like on<br>
> Windows. Major hard-to-build packages have been doing this for years:<br>
><br>
> wxPython<br>
> numpy, scipy, matplotlib<br>
><br>
> But these installers often don't work with virtualenv, and can't be<br>
> discovered or installed  pip or easy_install.<br>
><br>
> So I think it would be VERY useful if we established this standard for<br>
> PyPi and binary wheels.<br>
><br>
> macports, fink, and homebrew have been doing their own thing for ages,<br>
> and can continue to do so -- they HAVE package management built in,<br>
> just like the linux distros. If they want to do wheels, they will need<br>
> to make sure that the neccesary info is in the platform-tag. On my<br>
> <a href="http://python.org">python.org</a> build:<br>
><br>
> 'macosx-10.6-i386'<br>
><br>
> so they should patch their python to return something like:<br>
><br>
> 'macosx-macports-10.6-i386'<br>
><br>
> or just:<br>
><br>
> 'macports-10.6-i386'<br>
><br>
> and probably a macports version, rather than "10.6".<br>
><br>
> However, the _point_ of macports, homebrew, etc, is that your stuff is<br>
> all custom compiled for your system the way you have configured it --<br>
> so binary wheels really don't make sense.</p>
<p dir="ltr">PEP 453 has had most of my attention lately, but my tentative thought has been to introduce a relatively freeform "variant" field to the wheel spec.</p>
<p dir="ltr">Windows and Mac OS X would then default to an empty variant, while other *nix systems would require a nominated variant</p>
<p dir="ltr">That would then cover things like SSE builds on Windows, alternative sources on Mac OS X, etc.</p>
<p dir="ltr">However, worrying about that is a fair way down the todo list until ensurepip and the CPython doc updates for PEP 453 are done, along with everything else that has a 3.4b1 deadline :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -Chris<br>
><br>
> --<br>
><br>
> Christopher Barker, Ph.D.<br>
> Oceanographer<br>
><br>
> Emergency Response Division<br>
> NOAA/NOS/OR&R            (206) 526-6959   voice<br>
> 7600 Sand Point Way NE   (206) 526-6329   fax<br>
> Seattle, WA  98115       (206) 526-6317   main reception<br>
><br>
> <a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>