fwiw, just weighing in my opinion, this change does bring backwards incompatibility, and we definitely don't have any way of tagging to indicate a version of pip. So a python:2.7.12 pulled today is going to get 8.1.2, then pulling same image after this is merged is going to bring in 9.0.0 which may or may not break user applications.

Granted, I don't think that should hold us back from doing the upgrade, just something to keep in mind. I dealt with this when we upgraded to 8.0. :) See #83 for discussion.

Definitely need to figure out why tests are failing though.

Indeed, I'm wary of 9.0 given our experience with 8.0 (especially breaking our tests, which exposed a bug in pip itself). 😰

I'll have some time to look at this over the weekend and see if something obvious is standing out why tests would fail for this. 😭

I think the tests might actually be failing due to docker-library/official-images#2284 (docker-library/buildpack-deps#49, #151).

Which doesn't really make sense, given that buildpack-deps was updated in docker-library/official-images#2292 😞

😨 🙏

All test that fail, fail on master too. I'll guess it's best to fix the tests on master and then rebase.

Updated the commit to pip 9.0.1 and upgraded pip for the 3.6 image too (missed that before).

The tests pass now, I guess due to:

libgdbm-dev is not needed since docker-library/buildpack-deps#49, but it looks like there was a hiccup in the signing process and so the new image is not showing up on the Docker Hub.

See #156 (comment)

If upgrading pip is so critical, maybe there should be images for the latest major version of pip and the one before.

rebased

If upgrading pip is so critical, maybe there should be images for the latest major version of pip and the one before.

I wouldn't say it's necessarily critical, it's just caused problems in the past. I think we've got some pretty decent test coverage though, so I feel OK about updating this. 👍