<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 18, 2012, at 6:51 PM, Thomas Kluyver wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 19 September 2012 00:16, Matthew Brett &lt;<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>&gt; wrote:<br><blockquote type="cite">OK - but the website and the name point us to the standard, and thence<br></blockquote><blockquote type="cite">to some installers for that standard? &nbsp;&nbsp;You are not proposing any new<br></blockquote><blockquote type="cite">installers, but that the standard basically says something like:<br></blockquote><br>Yes, that's the idea.<br><br><blockquote type="cite">So, if we are adding packages to this collection, we are more or less<br></blockquote><blockquote type="cite">lobbying python (x, y) or EPD for those changes?<br></blockquote><br>I expect that the packages we're likely to specify are already<br>included in those distributions. We might end up lobbying for<br>additions to EPD Free, but I think that its description as 'Scientific<br>Python essentials' fits with what we're trying to achieve, so<br>hopefully Enthought are open to dialogue. This page shows what EPD<br>Free currently includes (packages with tick marks):<br><a href="http://www.enthought.com/products/epdlibraries.php">http://www.enthought.com/products/epdlibraries.php</a><br></div></blockquote><div><br></div><div>Don't forget about the new-comer to the freely-available binary distributions, Anaconda CE: which is a reference implementation as well and includes all the packages we are discussing: &nbsp;&nbsp;<a href="http://www.continuum.io/downloads.html">http://www.continuum.io/downloads.html</a></div><div><br></div><div>But, in general, the point of this conversation is not to lobby anyone to change their tools. &nbsp; It is to define what the community considers to be a reference implementation (however it is obtained) with version numbers of specific packages.</div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Good point. Can someone more Windows-savvy suggest how practical this<br>is? I assume the VS compiler can't be redistributed, so is mingw<br>sufficiently lightweight to expect all distributions to include it?<br>Many packages with compiled components provide executable installers<br>for Windows.<br></div></blockquote><div><br></div>It's easy to do. &nbsp; The next version of Anaconda CE is going to contain a C-compiler for Windows, for example. &nbsp; You can't really include Cython in the standard without a C-compiler. &nbsp; This, to me, makes the case for pylab-full (i.e. you want to have some definition that includes Cython, and you need a compiler to put Cython in there).&nbsp;</div><div><br></div><div><blockquote type="cite"><div><br>Also, I don't think Macs actually provide a C compiler - when I had to<br>test stuff on a Mac, I had to install Xcode before I could do<br>anything. Will distributions need to include a compiler on the Mac as<br>well, or would the wording of the definition exclude that?<br></div></blockquote><div><br></div>The best thing to do is just encourage people to install XCode, I think. &nbsp;<br><div><br></div><div>-Travis</div><div><br></div></div></body></html>