<p dir="ltr"><br>
On 22 Aug 2013 06:57, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 21 August 2013 21:35, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> I'm reasonably confident the wheel format *doesn't* meet the scientific community's needs in the general case, and can't be made to do so without a lot of additional complexity. That's why I explicitly support the hashdist/conda approach which abandons some of the goals of pip and wheel (notably, easier handling of security updates and easier conversion to Linux distro packages) in order to better handle complex binary dependencies.<br>

><br>
><br>
> While "the general case" may include some specialised situations, in my view, if the wheel format isn't a suitable replacement for bdist_wininst (and by implication, cannot be used by the numpy, scipy and similar projects to deliver Windows binary distributions) - maybe not for specialised use, but certainly for casual users like myself - then it will be essentially a failure.</p>

<p dir="ltr">Sure, it can replace bdist_wininst. What it *can't* do is tag an arbitrarily complex dependency tree the way hashdist can. So you're either going to need fat wheels which figure out the right binary extensions to use in a post-install hook, or else you're going to have to bless a default configuration that is published as a wheel.</p>

<p dir="ltr">Since wheel 1.0 has no support for post-install hooks, that option is not yet available, and I don't expect the idea of blessing a default binary version to be popular either.</p>
<p dir="ltr">><br>
> The only reason I am interested in wheels *at all* is as a format that allows me to "pip install" all those projects that currently provide bdist_wininst installers. In the first instance, via "wheel convert", but ultimately by the projects themselves switching from wininst format to wheel (or via some form of build farm mechanism, it doesn't matter to me, as long as the wheels are on PyPI).<br>

><br>
> Note that "wheel convert" is proof that this is the case right now, so this is not setting the bar unreasonably high. Nor am I saying that there's even a problem here at the moment. But if distutils-sig is sending a message that they don't think wheels are a suitable distribution format for (say) numpy or scipy, then I will be very disappointed.</p>

<p dir="ltr">Wheel is a suitable replacement for bdist_wininst (although anything that needs install hooks will have to wait for wheel 1.1, which will support metadata 2.0). It's just not a replacement for what hashdist and conda let you do when you care more about reproducibility than you do about security updates.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Paul</p>