[Distutils] latest setuptools appears to require six in a breaking way

[Matthew Brett]

Hi,

On Wed, Jan 25, 2017 at 4:52 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On Jan 25, 2017, at 12:27 PM, Eric Brunson <brunson at brunson.com> wrote:
>
> It wasn't until recently the I realized how quickly releases to setuptools
> and pip are being made, starting back in mid Dec when much of our dependency
> resolution started failing.  There were three releases in the past two days.
> Four major and 22 minor releases in the past two months.  While I applaud
> the speed of development and the improvement in these tools, don't you feel
> that breaking changes should be advertised better before release or perhaps
> we should slow down the cadence for release?
>
> I think an expectation that every setuptools user in the community start
> their day by checking to see if there was a release in the past 24 hours is
> a little unreasonable.  I've spent a dozen hours since 32.0.0 resolving
> breakage in my own projects and assisting other developers in my org with
> their setuptools issues, all the while pushing setuptools as the best
> practice to do development and distribution.  Is this period of breaking
> changes a short term thing that we just have to tough out for a few more
> weeks?
>
> Thanks,
> e.
>
>
>
> I don’t believe that pip is really releasing that quickly. We generally make
> 1-2 “major” versions a year that include breaking changes, 2-4 “minor”
> releases a year that add new features, and 6-10 patch releases that fix
> bugs. To me that feels like a pretty decent pace of balancing not breaking
> people and getting new changes into people’s hands and getting rid of broken
> or less optimal parts of the code.
>
> Now, setuptools is releasing faster than pip is and whether that’s a good
> thing or not I don’t know. That’s a question for Jason largely :)

It sounds like we need to get some continuous integration to bear on
this problem.

How about the following suggestion: before new releases, make release
candidates for pip, wheel, setuptools and virtualenv, upload to pypi,
announce here.

Then we the dependent projects can have a continuous integration entry
which tests our normal pip install with the --pre versions of these
packages, to screen for trouble.   I think that would catch many of
the problems, and it doesn't seem like it would be much work for the
package maintainers.

Cheers,

Matthew