Drop support for Python 2.6

[theacodes]

Resolves #298.

[theacodes]

(Don't merge until I verify that Travis still works)

[nathanielmanistaatgoogle]

I thought we were committed through 1 September. What am I missing? @thobrla, has something changed?

[thobrla]

No change on the gsutil side, still planning on removing Py 2.6. support from gsutil releases made after Sept 1.

[theacodes]

@nathanielmanistaatgoogle I don't anticipate us releasing 4.0.0 until september 1st, and going ahead and getting 2.6 out of the way will allow us to continue our hygiene cleanups unencumbered by 2.6

gcloud-python also dropped 2.6 support today. We're not alone.

[theacodes]

Travis flailing concluded. Everything is green and okay to merge.

[pferate]

Should we take care of unittest2 in this PR? Or create another PR?

[theacodes]

@pferate another PR, I just wanted to focus on removing the build system support and updated setup.py.

[nathanielmanistaatgoogle]

If we integrate this pull request now, doesn't that put us in an unreleasable state until 1 September? Or would we say something like "oh, use 3.x if you want 2.6 support"?

[theacodes]

If we integrate this pull request now, doesn't that put us in an unreleasable state until 1 September?

Only if we really want to hold steadfast to that date. We have essentially 3 downstream dependencies to worry about:

1. google-api-python-client, which you and I maintain.
2. gsutil, which hasn't updated to 3.0.0 yet.
3. gcloud-python, who just dropped 2.6 today.

[nathanielmanistaatgoogle]

So if we adopt this now, gsutil would have to pin their dependency on us to 3.0.0-or-lower through the end of this month? I recognize that the likelihood of problems is very small; I just want to make sure that the correct bounding box has been drawn around them.

[theacodes]

@thobrla can confirm, but I think they're currently bundling < 3.0.0 (maybe even less than 2.0.0).

[thobrla]

Correct - we would need to continue to pin to 3.0.0 or lower. We're already pinned to 2.2.0 because we have porting and integration testing work needed to adopt @jonparrott 's replacement for multistore_file.

[nathanielmanistaatgoogle]

... so @thobrla, it sounds like your explicit consent is needed for this merge? For you to say something like "gsutil will not move its oauth2client pin past 3.0.0 before 1 September"?

[thobrla]

Sorry - let me be clear. gsutil is fine with this merge; we won't move past 3.0.0 before 1 September. The caveat is if we find a critical bug in the 2.x branch, we'll need to fix it there and release.

[nathanielmanistaatgoogle]

Squash and merge!

[dhermes]

@pferate @jonparrott unittest2 can be squashed now if someone is up for it

[pferate]

We can easily use sed to go fromunittest2 -> unittest, or we can move the tests to pytest. I still have my branch for reference of the headaches I dealt with the first time I did that.

[dhermes]

Isn't the move to pytest still in progress?

[pferate]

I had a huge PR (#547) that did the full migration, but it was requested to break it up to make it easier to review.

[dhermes]

Gotcha. Brain dump PRs are difficult to review, I can sympathize. e.g. httplib2 wouldn't need to be in that PR.

I'll take a stab at it right now.