On Wed, Mar 18, 2015 at 8:43 AM, Paul Moore <p.f.moore@gmail.com> wrote:

> I suppose it's too late now, but the really painful parts of all this
> seem to be due to overly aggressive backward compatibility. We now
> have wheels, but also eggs, we now have pip, but also easy_install,
> etc.

Agreed. But the problem we have here is that any system that fails to
work for even a tiny proportion of packages on PyPI is a major issue.
And we don't have *any* control over those packages - if they do the
most insane things in their setup.py, and don't release a new version
using new tools, we have to support those insane things, or deal with
the bug reports.

Maybe we should say "sorry, your package needs to change or we won't
help"

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.

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? ;-) )

then folks couldn't simply replace:

from setuptool simport setup

with

from distribute import setup

and be done, but they would only make that change if they wanted to make that change.

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?)

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....

that way (see, for example, the distribute or distutils2 flamewars).

IIRC, distribute was always imported as "setuptools" -- so born to create strife and/or accumulate all the same kruft.

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...

Agreed entirely. It's a long slow process though to migrate away from
the problems of setuptools without losing the great features at the
same time...

That slog is MUCH longer and harder if you need to keep backward compatibility though.

But I suppose the alternative is to build something no one uses!

Is there any move to have a deprecation process for setuptools features?

-Chris

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA 98115   (206) 526-6317   main reception

Chris.Barker@noaa.gov