[Distutils] setup_requires for dev environments

[Chris Barker]

On Wed, Mar 18, 2015 at 8:43 AM, Paul Moore <p.f.moore at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150319/33f3c2ab/attachment.html>