New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop support for Python 2.6 #590

Merged
merged 7 commits into from Aug 9, 2016

Conversation

Projects
None yet
6 participants
@theacodes
Member

theacodes commented Aug 4, 2016

Resolves #298.

@theacodes

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 4, 2016

Member

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

Member

theacodes commented Aug 4, 2016

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

@@ -1,15 +1,7 @@
language: python
python: 2.7

This comment has been minimized.

@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 4, 2016

Contributor

I don't understand the changes on lines two through nine of this file.

@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 4, 2016

Contributor

I don't understand the changes on lines two through nine of this file.

This comment has been minimized.

@theacodes

theacodes Aug 4, 2016

Member

-python 2.7 isn't required as by default travis will expose all available python interpreters.

The matrix part shouldn't be needed anymore, as travis should provide the 3.5 interpreter. (this needs to be verified)

@theacodes

theacodes Aug 4, 2016

Member

-python 2.7 isn't required as by default travis will expose all available python interpreters.

The matrix part shouldn't be needed anymore, as travis should provide the 3.5 interpreter. (this needs to be verified)

@nathanielmanistaatgoogle

This comment has been minimized.

Show comment
Hide comment
Contributor

nathanielmanistaatgoogle commented Aug 4, 2016

@thobrla

This comment has been minimized.

Show comment
Hide comment
@thobrla

thobrla Aug 4, 2016

Contributor

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

Contributor

thobrla commented Aug 4, 2016

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

@theacodes

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 4, 2016

Member

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

Member

theacodes commented Aug 4, 2016

@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 added some commits Aug 4, 2016

@theacodes theacodes removed the don't merge label Aug 4, 2016

@theacodes

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 4, 2016

Member

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

Member

theacodes commented Aug 4, 2016

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

@pferate

This comment has been minimized.

Show comment
Hide comment
@pferate

pferate Aug 4, 2016

Contributor

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

Contributor

pferate commented Aug 4, 2016

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

@theacodes

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 4, 2016

Member

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

Member

theacodes commented Aug 4, 2016

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

@nathanielmanistaatgoogle

This comment has been minimized.

Show comment
Hide comment
@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 4, 2016

Contributor

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

Contributor

nathanielmanistaatgoogle commented Aug 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 4, 2016

Member

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

theacodes commented Aug 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 5, 2016

Contributor

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.

Contributor

nathanielmanistaatgoogle commented Aug 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@theacodes

theacodes Aug 5, 2016

Member

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

Member

theacodes commented Aug 5, 2016

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

@thobrla

This comment has been minimized.

Show comment
Hide comment
@thobrla

thobrla Aug 8, 2016

Contributor

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.

Contributor

thobrla commented Aug 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 9, 2016

Contributor

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

Contributor

nathanielmanistaatgoogle commented Aug 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@thobrla

thobrla Aug 9, 2016

Contributor

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.

Contributor

thobrla commented Aug 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathanielmanistaatgoogle

nathanielmanistaatgoogle Aug 9, 2016

Contributor

Squash and merge!

Contributor

nathanielmanistaatgoogle commented Aug 9, 2016

Squash and merge!

- python: 2.7
env: TOX_ENV=system-tests
- python: 3.4
env: TOX_ENV=system-tests3

This comment has been minimized.

@pferate

pferate Aug 9, 2016

Contributor

Sorry for the late comment. What do you think using something like tox-travis to simplify this part.

@pferate

pferate Aug 9, 2016

Contributor

Sorry for the late comment. What do you think using something like tox-travis to simplify this part.

This comment has been minimized.

@dhermes

dhermes Aug 9, 2016

Contributor

@pferate Thanks for bringining tox-travis to my attention!

@dhermes

dhermes Aug 9, 2016

Contributor

@pferate Thanks for bringining tox-travis to my attention!

This comment has been minimized.

@theacodes

theacodes Aug 9, 2016

Member

I'm ambivalent.

@theacodes

theacodes Aug 9, 2016

Member

I'm ambivalent.

@theacodes theacodes merged commit 2e8d1be into googleapis:master Aug 9, 2016

3 checks passed

cla/google All necessary CLAs are signed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 100.0%
Details

@theacodes theacodes deleted the theacodes:drop-2.6 branch Aug 9, 2016

@dhermes

This comment has been minimized.

Show comment
Hide comment
@dhermes

dhermes Aug 10, 2016

Contributor

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

Contributor

dhermes commented Aug 10, 2016

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

@pferate

This comment has been minimized.

Show comment
Hide comment
@pferate

pferate Aug 10, 2016

Contributor

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.

Contributor

pferate commented Aug 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dhermes

dhermes Aug 10, 2016

Contributor

Isn't the move to pytest still in progress?

Contributor

dhermes commented Aug 10, 2016

Isn't the move to pytest still in progress?

@pferate

This comment has been minimized.

Show comment
Hide comment
@pferate

pferate Aug 11, 2016

Contributor

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.

Contributor

pferate commented Aug 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dhermes

dhermes Aug 11, 2016

Contributor

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.

Contributor

dhermes commented Aug 11, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment