<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 12:38 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</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>On 1 December 2013 22:17, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>


<br>
> For example, I installed Nikola into a virtualenv last night. That required<br>
> installing the development headers for libxml2 and libxslt, but the error<br>
> that tells you that is a C compiler one.<br>
><br>
> I've been a C programmer longer than I have been a Python one, but I still<br>
> had to resort to Google to try to figure out what dev libraries I needed.<br>
<br>
</div>But that's a *build* issue, surely? How does that relate to installing<br>
Nikola from a set of binary wheels?<br>
<br>
I understand you are thinking about non-Python libraries, but all I<br>
can say is that this has *never* been an issue to my knowledge in the<br>
Windows world. People either ship DLLs with the Python extension, or<br>
build statically. I understand that things are different in the Unix<br>
world, but to be blunt why should Windows users care?<br>
<div><br>
> Outside the scientific space, crypto libraries are also notoriously hard to<br>
> build, as are game engines and GUI toolkits. (I guess database bindings<br>
> could also be a problem in some cases)<br>
<br>
</div>Build issues again...<br>
<div><br>
> We have the option to leave handling the arbitrary binary dependency problem<br>
> to platforms, and I think we should take it.<br>
<br>
</div>Again, can we please be clear here? On Windows, there is no issue that<br>
I am aware of. Wheels solve the binary distribution issue fine in that<br>
environment (I know this is true, I've been using wheels for months<br>
now - sure there may be specialist areas that need some further work<br>
because they haven't had as much use yet, but that's details)<br>
<div><br>
> This is why I suspect there will be a better near term effort/reward<br>
> trade-off in helping the conda folks improve the usability of their platform<br>
> than there is in trying to expand the wheel format to cover arbitrary binary<br>
> dependencies.<br>
<br>
</div>Excuse me if I'm feeling a bit negative towards this announcement.<br>
I've spent many months working on, and promoting, the wheel + pip<br>
solution, to the point where it is now part of Python 3.4. And now<br>
you're saying that you expect us to abandon that effort and work on<br>
conda instead? I never saw wheel as a pure-Python solution, installs<br>
from source were fine for me in that area. The only reason I worked so<br>
hard on wheel was to solve the Windows binary distribution issue. If<br>
the new message is that people should not distribute wheels for (for<br>
example) lxml, pyyaml, pymzq, numpy, scipy, pandas, gmpy, and pyside<br>
(to name a few that I use in wheel format relatively often) then<br>
effectively the work I've put in has been wasted.<br></blockquote><div><br></div><div>Hi, scipy developer here. In the scientific python community people are definitely interested in and intending to standardize on wheels. Your work on wheel + pip is much appreciated.<br>

<br></div><div>The problems above that you say are "build issues" aren't really build issues (where build means what distutils/bento do to build a package). Maybe the following concepts, shamelessly stolen from the thread linked below, help:<br>
</div><div>- *build systems* handle the actual building of software, eg Make, CMake, distutils, Bento, autotools, etc<br></div><div>- *package managers* handle the distribution and installation of built (or source) software, eg pip, apt, brew, ports<br>

</div><div>- *build managers* are separate from the above and handle the automatic(?) preparation of packages from the results of build systems<br><br></div><div>Conda is a package manager to the best of my understanding, but because it controls the whole stack it can also already do parts of the job of a build manager. This is not something that pip aims to do. Conda is fairly new and not well understood in our community either, but maybe this (long) thread helps: <br>
</div><div><a href="https://groups.google.com/forum/#!searchin/numfocus/build$20managers/numfocus/mVNakFqfpZg/6h_SldGNM-EJ" target="_blank">https://groups.google.com/forum/#!searchin/numfocus/build$20managers/numfocus/mVNakFqfpZg/6h_SldGNM-EJ</a>. <br>
<br></div><div>Regards,<br>Ralf<br></div><div>
<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 hoping I've misunderstood here. Please clarify. Preferably with<br>
specifics for Windows (as "conda is a known stable platform" simply<br>
isn't true for me...) - I accept you're not a Windows user, so a<br>
pointer to already-existing documentation is fine (I couldn't find any<br>
myself).<br>
<span><font color="#888888"><br>
Paul.<br>
</font></span><div><div>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</div></div></blockquote></div><br></div></div>