<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><br>
On Dec 3, 2013, at 7:36 PM, Oscar Benjamin <<a href="mailto:oscar.j.benjamin@gmail.com">oscar.j.benjamin@gmail.com</a>> wrote:<br>
<br>
> On 3 December 2013 21:13, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
>> I think Wheels are the way forward for Python dependencies. Perhaps not for<br>
>> things like fortran. I hope that the scientific community can start<br>
>> publishing wheels at least in addition too.<br>
><br>
> The Fortran issue is not that complicated. Very few packages are<br>
> affected by it. It can easily be fixed with some kind of compatibility<br>
> tag that can be used by the small number of affected packages.<br>
><br>
>> I don't believe that Conda will gain the mindshare that pip has outside of<br>
>> the scientific community so I hope we don't end up with two systems that<br>
>> can't interoperate.<br>
><br>
> Maybe conda won't gain mindshare outside the scientific community but<br>
> wheel really needs to gain mindshare *within* the scientific<br>
> community. The root of all this is numpy. It is the biggest dependency<br>
> on PyPI, is hard to build well, and has the Fortran ABI issue. It is<br>
> used by very many people who wouldn't consider themselves part of the<br>
> "scientific community". For example matplotlib depends on it. The PyPy<br>
> devs have decided that it's so crucial to the success of PyPy that<br>
> numpy's basically being rewritten in their stdlib (along with the C<br>
> API).<br>
><br>
> A few times I've seen Paul Moore refer to numpy as the "litmus test"<br>
> for wheels. I actually think that it's more important than that. If<br>
> wheels are going to fly then there *needs* to be wheels for numpy. As<br>
> long as there isn't a wheel for numpy then there will be lots of<br>
> people looking for a non-pip/PyPI solution to their needs.<br>
><br>
> One way of getting the scientific community more on board here would<br>
> be to offer them some tangible advantages. So rather than saying "oh<br>
> well scientific use is a special case so they should just use conda or<br>
> something", the message should be "the wheel system provides solutions<br>
> to many long-standing problems and is even better than conda in (at<br>
> least) some ways because it cleanly solves the Fortran ABI issue for<br>
> example".<br>
><br>
><br>
> Oscar<br>
<br>
</div></div>I’d love to get Wheels to the point they are more suitable then they are for<br>
SciPy stuff,</blockquote><div><br></div><div>That would indeed be a good step forward. I'm interested to try to help get to that point for Numpy and Scipy.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 I’m not sure what the diff between the current state and what<br>
they need to be are but if someone spells it out (I’ve only just skimmed<br>
your last email so perhaps it’s contained in that!) I’ll do the arguing for it. I<br>
just need someone who actually knows what’s needed to advise me :)<br></blockquote><div><br></div><div>To start with, the SSE stuff. Numpy and scipy are distributed as "superpack" installers for Windows containing three full builds: no SSE, SSE2 and SSE3. Plus a script that runs at install time to check which version to use. These are built with ``paver bdist_superpack``, see <a href="https://github.com/numpy/numpy/blob/master/pavement.py#L224">https://github.com/numpy/numpy/blob/master/pavement.py#L224</a>. The NSIS and CPU selector scripts are under tools/win32build/.<br>
<br></div><div>How do I package those three builds into wheels and get the right one installed by ``pip install numpy``?<br><br></div><div>If this is too difficult at the moment, an easier (but much less important one) would be to get the result of ``paver bdist_wininst_simple`` as a wheel.<br>
<br></div><div>For now I think it's OK that the wheels would just target 32-bit Windows and <a href="http://python.org">python.org</a> compatible Pythons (given that that's all we currently distribute). Once that works we can look at OS X and 64-bit Windows.<br>
</div><div><br></div><div>Ralf</div><div><br></div></div></div></div>