Skip to content
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

Pytzectomy #11360

Merged
merged 10 commits into from Jul 9, 2018
Merged

Pytzectomy #11360

merged 10 commits into from Jul 9, 2018

Conversation

pganssle
Copy link
Member

@pganssle pganssle commented Jun 1, 2018

PR Summary

Closes #10443.

This removes pytz as a required dependency in favor of dateutil.tz, for the reasons detailed in the ticket. In addition to the "removing an unnecessary dependency" aspect of this, I have fleshed out the reasons to use dateutil over pytz in this blog post. I considered linking to the blog post in the "API changes" section to explain more of the reasoning, but I'm not sure it's actually necessary.

With regards to the testing, there may already be enough baseline "both pytz and dateutil" testing to ensure that pytz is still a supported option (specifically the test_rrulewrapper_pytz covers both the most important corner case and the use of pytz on an axis), but it wouldn't be a bad idea to add a few more tests for that. I recommend making sure that pytz is not installed during the main tests, though (the way I set it up the pytz-specific tests are run through tox so that it is only installed in the virtualenv), to avoid any accidental implicit dependencies that may arise.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@pganssle
Copy link
Member Author

pganssle commented Jun 1, 2018

I'm getting the same Travis failures from invoking tox in my home directory. Is using tox not supported?

I will note that I've actually really liked it ever since I started using tox to drive all the builds and have both Travis and Appveyor just invoke various tox testenvs. Might not be a bad idea to switch matplotlib over to doing something similar (though because matplotlib has a much more expensive build, it's probably a good idea to figure out how to cache the builds between environments and such.

@pganssle
Copy link
Member Author

I think the difference in code coverage comes from the fact that there's a net negative number of covered lines in the PR, not any changes to the actual coverage.

@jklymak jklymak added this to the v3.0 milestone Jun 12, 2018
@jklymak
Copy link
Member

jklymak commented Jun 12, 2018

On gitter you suggested this should be a blocker for 3.0. Care to elaborate the argument?

@pganssle
Copy link
Member Author

@jklymak In the original issue #10443, I suggested that this be done as part of a major release, because there is an argument to be made that this would break backwards compatibility in some rare situations, since pytz timezones have a different interface than standard tzinfo classes.

While one could argue that you maybe shouldn't be counting on the fact that the timezones used by matplotlib itself are pytz objects, I think the best thing to do is to just do it as part of a backwards-compat-breaking release. Preferably that would be 3.0 and not some future breaking release.

@jklymak
Copy link
Member

jklymak commented Jun 12, 2018

I'm still not sure how we feel about the tox requirement for the testing, so haven't reviewed this. The general idea seems fine to me...

.travis.yml Outdated
@@ -195,6 +196,7 @@ before_script: |
script: |
echo "Calling pytest with the following arguments: $PYTEST_ADDOPTS"
python -mpytest
tox -e pytz
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that doing two full test suites, one with and one without pytz? If yes, that's way too much; if no, what is this doing?

In general I agree with @jklymak that we probably don't want the test suite to be based on tox.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, tox -e pytz only runs the pytz environment, which runs pytest -m pytz, and thus only runs tests decorated with pytest.mark.pytz.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try adding a set -e to the script section? or combining the two lines via &. I think the issue is that the return value from the script section is the return of the last thing called.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I came to this conclusion as well, though the main problem with this is that if the first one fails the second one won't be run at all.

Ideally the main test suite would also be run with tox, so that you can do:

tox -e py,pytz

Which would run both environments and have a single return code. If the project doesn't want to use tox as the main test runner, we can use the -e or pytest ... && tox -e pytz solution as a "for now" and leave it to a later PR to refactor the test suite as preferred.


from matplotlib.testing.decorators import image_comparison
import matplotlib.pyplot as plt
from matplotlib.cbook import MatplotlibDeprecationWarning
import matplotlib.dates as mdates


def __has_pytz():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double underscore seems a bit overkill

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong preference here. I think I used double underscore because I intended it to be ephemeral. I think maybe I should switch it to:

def __has_pytz():
    ...
HAS_PYTZ = __has_pytz()
del __has_pytz()

We can drop the del line and switch to a single underscore if that's preferred style.

_test_rrulewrapper(attach_tz, dateutil.tz.gettz)


@pytest.mark.pytz
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this mark?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All otherwise unspecified marks are used to register a test with the mark of that name. This indicates that the decorated test uses pytz, so that you can filter out tests that require pytz (or that don't require pytz).

@pganssle
Copy link
Member Author

I'm still not sure how we feel about the tox requirement for the testing, so haven't reviewed this. The general idea seems fine to me...

I think the tox thing doesn't really matter very much. It's just a convenient way to run the test with its own virtual environment so that pytz doesn't need to be installed during the main run of the tests. End users probably will have pytz installed (or can install it themselves), and the pytz-specific tests are opportunistic in that they will run whenever pytz is installed.

In any case, I think it should probably not block this PR for the following reasons:

  1. So long as tox.ini exists, it's actually probably good to have a test that uses it, since otherwise it's prone to bitrot. If you want to drop tox entirely, I think a separate PR that removes tox and replaces it in this case would be appropriate.
  2. It is only a build-time dependency and has no impact on end-users, and it already works. There's almost no cost to doing it this way and it can be changed at any point on master, whereas the substantive changes should be in before 3.0 and are user facing.

import pytz
return True
except ImportError:
return False
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, disturbing that this line isn't being hit. Something is indirectly pulling in a pytz dependency in the main test suite.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the problem is pandas. I was under the impression that the pandas integration tests were being run separately from the main test suite. If that's no longer the case, then this is a bit of a problem, since you could have implicit dependencies on any of the pandas dependencies.

@jklymak
Copy link
Member

jklymak commented Jul 5, 2018

This seems like a useful PR that has hung up because of how the tests are set up. Can we defer the argument about tox for a different PR, and set these tests up more traditionally so we can merge it before 3.0?

Of course if the tox setup is something core devs with more experience with the test setup want to keep, please feel free to move forward w/ this. I'm only objecting out of lack of familiarity and because its not something we typically do, not for any fundamental reasons.

@jklymak jklymak added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Jul 5, 2018
@pganssle
Copy link
Member Author

pganssle commented Jul 5, 2018

@jklymak I do think we should try and get this merged ASAP, but the problem of tox vs. no tox is not the main problem. The main reason I brought in tox was because I was trying to run the tests without pytz to prove that matplotlib doesn't have an unnoticed dependency on pytz, but also have some tests that run with pytz installed to prove that matplotlib still works if you give it pytz datetimes.

The problem is that the pandas tests are no longer run in a separate environment from the rest of the tests, and pandas pulls in pytz. I'm not really sure where to go from here. Should we separate the pandas tests back out? Should we try to run just the explicitly datetime-related tests that don't overlap with the pandas-specific tests in a fresh environment with no pytz installed?

I would advocate for running all tests that involve optional dependencies in separate environments to avoid accidentally upgrading them from optional to required dependencies.

@tacaswell
Copy link
Member

We should be running at least one test without pandas (see https://travis-ci.org/matplotlib/matplotlib/jobs/391289494#L2387 where one of these test suites is skipping due to a missing pandas dep).

Can your rebase this (the requirements got re-organized into stand-alone-files recently)?

I am worried that we have coverage set up slightly wrong and it is not properly merging reports...

@pganssle
Copy link
Member Author

pganssle commented Jul 5, 2018

@tacaswell OK, done. Hopefully I got the travis configuration right.

@pganssle
Copy link
Member Author

pganssle commented Jul 5, 2018

On the job you link to, did you notice line 2381?

....................Coverage.py warning: No data was collected. (no-data-collected)

Presumably that is the problem? Not sure why, though.

@pganssle
Copy link
Member Author

pganssle commented Jul 5, 2018

I can't really make heads or tails of what's going on here. This CI run has actual test failures!, but it still gets a green check.

Edit: This may be because I'm running tox -e pytz afterwards, so only the return value of the last run tests matters.

@tacaswell
Copy link
Member

The culprit installing pytz is sphinx via babel

Collecting pytz>=0a (from babel!=2.0,>=1.3->sphinx->-r requirements/testing/travis_all.txt (line 18))

@pganssle may I push to your branch?

@pganssle
Copy link
Member Author

pganssle commented Jul 5, 2018

@tacaswell Good find, go for it.

@pganssle
Copy link
Member Author

pganssle commented Jul 6, 2018

Looks like the coverage problem is fixed, so I'm going to go ahead and squash my fixup commits.

@pganssle pganssle force-pushed the pytzectomy branch 2 times, most recently from 1a12144 to 7578b32 Compare July 6, 2018 14:03
@tacaswell
Copy link
Member

In the interest of expediancy we are merging allowing that wx failure on mac (which we are still having issues sorting out if it is a bug on our side or dependent on the wx version).

@pganssle
Copy link
Member Author

pganssle commented Jul 6, 2018

@tacaswell I squashed your last commit into the one where the .travis.yml was originally changed - I think that was an artifact of the merge conflict from the original rebase.

Copy link
Member

@jklymak jklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, except for the test stuff I still haven't groked.

@jklymak
Copy link
Member

jklymak commented Jul 6, 2018

Any chance this can be squashed before merging?

@pganssle
Copy link
Member Author

pganssle commented Jul 6, 2018

I can squash it if you want, but I'm pretty meticulous about my history, so I always squash related commits and use small, atomic commits so it's cleaner when looking through the history or doing a git bisect. I've already squashed all the various fixups (except for Tom's, but I can squash those all into the CI-changes commit if you'd prefer).

@jklymak
Copy link
Member

jklymak commented Jul 6, 2018

The artistry of how much gets squashed before a merge is beyond my pay grade - just noting that we don't usually have 9 commits for a change this size.

@tacaswell
Copy link
Member

@pganssle I rebased and force-pushed to your branch to resolve a conflict in the travis file.

@tacaswell
Copy link
Member

Actually, force-pushed twice to fix a commit message. Plan to merge this when it passes if @pganssle do not protest.

pganssle and others added 9 commits July 8, 2018 15:18
The separate tests with and without pytz are done to try to minimize the
possibility of implicit dependencies on pytz.

Run the second test in it's own entry in the script section of the
travis file so that it does not mask failures from other sections.
Sphinx pulls in pytz which we want to avoid to test running without
it.

The sphinx related code is well tested by the circle CI that builds
the docs.
@pganssle
Copy link
Member Author

pganssle commented Jul 8, 2018

I re-signed all my commits (I don't know if you care about that). Feel free to merge whenever, or just let me know how you'd like the commits squashed and I can squash and sign the squashed commits.

@tacaswell
Copy link
Member

Great, will merge this when it passes.

@dstansby
Copy link
Member

dstansby commented Jul 9, 2018

Looks like the tox call is creating a bunch of extra files, which the PEP8 checker doesn't like, maybe adding .tox/* to .gitignore will help, or similar thing to the PEP8 configuration file?

@tacaswell tacaswell merged commit 9324b27 into matplotlib:master Jul 9, 2018
@tacaswell
Copy link
Member

Thanks @pganssle !

This was a PR that travis did not want to go in....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. topic: date handling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants