<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 10:17 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 21 October 2015 at 17:42, Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br>
> So why not have a setuptools-lite that only does the building? </span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In general, this sounds like a reasonable idea. But, there are the<br>
usual problems:<br>
<br>
1. Someone needs to do the work.<br></blockquote><div><br></div><div>well, yeah -- that's the always the big problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Backward compatibility (as in, there's bound to be some projects<br>
out there using whatever functionality you can think of that "nobody<br>
would ever need"...)<br></blockquote><div><br></div><div>actually, this is exactly the problem I'm trying to address with this idea. Lots of people use setuptools, and you can bet the someone, somewhere, is using every little feature (and counting on a bug) than it has. Which is why distribute merged into setuptools -- I wasn't involved in the conversation at that point, but I think it more or less started as a "new, better, setuptools replacement", and then turned into a "maintained and updated setuptools". </div><div><br></div><div>What I do remember from those days is that setuptools itself had fallen into a maintenance hole -- very frustrating. But fixing that means that distribute lost its goal of actually making it better.</div><div><br></div><div>The idea here is to provide an upgrade path -- if you want to do thing the new way (the sane way :-) ), then drop in setuptools_lite, and see what breaks -- then decide to remove or refactor the things that setuptools_lite doesn't support, or just go back to setuptools.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">3. You can't call it setuptools, and pip "injects" the real setuptools<br>
into projects when building/installing. Pretending to be setuptools<br>
was what made distribute such a PITA to deal with, and I don't imagine<br>
we'd ever want to go there again.<br></blockquote><div><br></div><div>no -- it would be setuptools_lite -- different name :-) Or it would be a somewhat-disabled setuptools -- which would be the distribute problem again. But I _think_ the problem with distribute was that people WANTED it to have all the functionality of setuptools -- and going back to setuptools wasn't a good option because it was no longer well maintained (see above). Granted, I wasn't in the trenches then, or even lurking -- but I was a user, and trying to teach python newbies what to do -- and yes, it did kind of suck.</div><div><br></div><div>As I understand it, pip injects setuptools because pip really needs a build tool that does things that distutils doesn't. And there are no other build tools. But that architecture really sucks -- pip should not have to rely on injecting a particular package, but rather be able to rely on a given API to be available.</div><div><br></div><div>I have no idea how we can get from here to there cleanly, but it would it be that big a deal for pip to look for either setuptools or setuptools_lite, and neither are there, inject setuptools_lite. </div><div><br></div><div>The whole point is that setuptools_lite would have everything that pip needs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry, I'm being a downbeat grump today.</blockquote><div><br></div><div>not at all -- this has been an ugly mess for a long time -- we really, really need the folks with experience to keep things in check :-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> The reality is that far and<br>
away the best shot we've had at getting out of this mess is the plan<br>
we're currently working to, which is to standardise interfaces, and<br>
once we have some standards, we can start decoupling the various bits<br>
and *then* replacing them as needed.</blockquote><div><br></div><div>well, yes. But my idea here is to have something for users to do in the interim -- right now, I HAVE to use setuptools -- it's the only thing that knows how to find the compiler on Windows, and pip needs it to install.</div><div><br></div><div>So there is no way for me not to find it really easy to accidentally use setuptools features that I don't want to use, and "shouldn't" use. </div><div><br></div><div>So while we are waiting for the grand future of clear APIs and well-defined components, we can start getting people ready for that....</div><div><br></div><div>As I write this, I'm starting to think that despite my post a half hour ago, probably the best way to do this is to add a __future__ feature to setuptools:</div><div><br></div><div>import setuptools</div><div>setuptools.__future__()</div><div><br></div><div>or some such -- all it would do is remove and/or turn off stuff setuptools should no longer be doing.</div><div><br></div><div>And this might actually help with the "standardise interfaces" part of the project. Essentially a working prototype of what the build tool needs to support. If turn off a feature, we may find that it's needed -- then we can decide where that feature needs to live.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But if you want to<br>
rework the existing toolset, you're probably going to be on your own<br>
(and there's unfortunately a risk that you'll pull attention away from<br>
other work via debates on this list etc).<br></blockquote><div><br></div><div>Fair enough -- though I"m thinking of this as both a way to get something useful sooner than later, AND a way to maybe test out some of the API ideas. After all, there have been efforts to just build something new -- distutils2, etc -- maybe we need a more transitional, try it as you go approach.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As a thought, does anyone feel like working on an<br>
"interoperability standards roadmap" that provides a reference for<br>
where the PyPA see things going? </blockquote><div><br></div><div>That would be great, yes!</div><div> </div><div>-CHB</div><div><br></div></div><br clear="all"><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>