<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 12:26 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On October 21, 2015 at 3:13:11 PM, Chris Barker (<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>) wrote:<br>
><br>
> replace all your "import setuptools" with "import setuptool_lite" would be<br>
> clear what the intent was -- i.e. not YET ANOTHER brand new build system...<br></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moving from one “one true build system” to another “one true build system” is unlikely.</blockquote><div><br></div><div>sure -- but I'm not even talking about another special purpose build system.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A far better approach IMO is the one we’re taking. Define standard *formats* and let end users select whatever tool they want to create things that adhere to that format.</blockquote><div><br></div><div>yes -- fabulous -- but you need API as well as format, yes? i.e if pip is going to be able to find a source package and build and install it, it needs to know how to do that, ideally without knowing what the build tool is. So that's API, yes?</div><div><br></div><div>(maybe plain old setup.py build" is a fine API...</div><div><br></div><div>As I understand it, the current "API" that pip knows about is:</div><div><br></div><div>"some subset of what setuptools provides"</div><div><br></div><div>So my proposal is here is to provide a way for users to easily use jsut that subset. This would:</div><div><br></div><div>- give folks like me a way to avoid easy-install, etc...</div><div>- give all of us a way to start moving our packages to a structure that will be better suited to the upcoming orthogonal build-install toolchains.</div><div>- give those folks involved in the planning a concrete way to know, for sure what people really need (or really use, anyway), both for features and API. </div><div><br></div><div>In short -- aside from the distraction issue, this is a way to help us get to the future we want, not an alternative to that future.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This lets people create really focused tools for particular use cases, you can have a dead simple one for pure python things that never need to worry about the complexity of building C libraries</blockquote><div><br></div><div>which distutils isn't so bad at, eh? :-)</div><div><br></div><div>-CHB</div><div><br></div><div> </div></div><div><br></div>-- <br><div class="gmail_signature"><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" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>