<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 18, 2015 at 8:43 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I suppose it's too late now, but the really painful parts of all this<br>
> seem to be due to overly aggressive backward compatibility. We now<br>
> have wheels, but also eggs, we now have pip, but also easy_install,<br>
> etc.<br>
<br>
</span>Agreed. But the problem we have here is that any system that fails to<br>
work for even a tiny proportion of packages on PyPI is a major issue.<br>
And we don't have *any* control over those packages - if they do the<br>
most insane things in their setup.py, and don't release a new version<br>
using new tools, we have to support those insane things, or deal with<br>
the bug reports.<br>
<br>
Maybe we should say "sorry, your package needs to change or we won't<br>
help"</blockquote><div><br></div><div>Indeed -- I agree that it's key to support all the old kruft -- but it's key to support that with the package manger / installation tool, i.e. pip. We want pip install to "just work" for most of the packages already on PyPi for sure.</div><div><br></div><div>But that doesn't mean that the newer-and-better setuptools needs to support all the same old cruft. If it were called something different: (distribute? ;-) )</div><div><br></div><div>then folks couldn't simply replace:</div><div><br></div><div>from setuptool simport setup </div><div>with </div><div>from distribute import setup</div><div><br></div><div>and be done, but they would only make that change if they wanted to make that change.</div><div><br></div><div>Of course, then we'd be supporting both setuptools and distribute, and having to make sure that pip (and wheel) worked with both... so maybe just too much a maintenance headache, but breaking backward compatibility gets you a way forward that keeping it does not (py3 anyone?)</div><div><br></div><div>I suppose the greater danger is that every feature in setuptools is there because someone wanted it -- so it would be easy for the "new" thing to grow all the same kruft....</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">that way (see, for example, the distribute or distutils2 flamewars).<br></blockquote><div><br></div><div>IIRC, distribute was always imported as "setuptools" -- so born to create strife and/or accumulate all the same kruft.</div><div><br></div><div>I guess I have no idea if there was a big problem with the architecture of setuptools requiring a big shift -- all I see are problems with the API and feature set.....and by definition you can't change those and be backward compatible...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agreed entirely. It's a long slow process though to migrate away from<br>
the problems of setuptools without losing the great features at the<br>
same time...<br></blockquote><div><br></div><div>That slog is MUCH longer and harder if you need to keep backward compatibility though. </div></div><div><br></div><div>But I suppose the alternative is to build something no one uses!</div><div><br></div><div>Is there any move to have a deprecation process for setuptools features?</div><div><br></div><div>-Chris</div><div><br></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>