Skip to content

DEPS: drop numpy < 1.12 #23062

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

Merged
merged 45 commits into from
Oct 15, 2018
Merged

DEPS: drop numpy < 1.12 #23062

merged 45 commits into from
Oct 15, 2018

Conversation

h-vetinari
Copy link
Contributor

@h-vetinari h-vetinari commented Oct 9, 2018

Spurred on also partly by compat failure of #22725. ;-)

@pep8speaks
Copy link

pep8speaks commented Oct 9, 2018

Hello @h-vetinari! Thanks for updating the PR.

Comment last updated on October 12, 2018 at 16:26 Hours UTC

@h-vetinari h-vetinari mentioned this pull request Oct 9, 2018
3 tasks
@codecov
Copy link

codecov bot commented Oct 9, 2018

Codecov Report

Merging #23062 into master will increase coverage by 0.04%.
The diff coverage is 94.73%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #23062      +/-   ##
==========================================
+ Coverage   92.14%   92.19%   +0.04%     
==========================================
  Files         170      170              
  Lines       51017    50963      -54     
==========================================
- Hits        47011    46984      -27     
+ Misses       4006     3979      -27
Flag Coverage Δ
#multiple 90.61% <94.73%> (+0.04%) ⬆️
#single 42.29% <31.57%> (-0.02%) ⬇️
Impacted Files Coverage Δ
pandas/plotting/_converter.py 63.82% <ø> (-0.07%) ⬇️
pandas/util/_test_decorators.py 93.24% <ø> (+0.56%) ⬆️
pandas/plotting/_style.py 75% <100%> (+0.71%) ⬆️
pandas/plotting/_compat.py 87.5% <100%> (-3.81%) ⬇️
pandas/plotting/_core.py 83.63% <100%> (+0.27%) ⬆️
pandas/core/computation/check.py 90.9% <100%> (ø) ⬆️
pandas/core/algorithms.py 95.12% <100%> (+0.55%) ⬆️
pandas/core/ops.py 94.63% <100%> (+0.24%) ⬆️
pandas/compat/numpy/__init__.py 92.85% <80%> (-1.09%) ⬇️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf11f71...d097b43. Read the comment docs.

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

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

Generally good; looks like there's a dependency conflict between bottleneck and numpy

@@ -11,7 +11,7 @@ dependencies:
- matplotlib
- nomkl
- numexpr
- numpy=1.10.4
- numpy=1.12.1
Copy link
Member

Choose a reason for hiding this comment

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

Most of the code / docs point to 1.12.0 but this is 1.12.1 - any reason for the minor version bump here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, that was an oversight...

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

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

Can you also add the minimum version to the appropriate requirements file(s) in the ci folder?

FYI I know that bumping Matplotlib to a min of 2.0 also calls for some code cleanup / removal. OK to tackle that in a separate PR - do you mind opening the issue for that?

@h-vetinari
Copy link
Contributor Author

@WillAyd
I did it right here (where it belongs IMO). Not sure I got everything, because there are some Win32 errors in the plotting tests that were already there before.

@jreback
Copy link
Contributor

jreback commented Oct 9, 2018

i don’t think any real urgency to bump numexpr or bottleneck mins

we generally try to allow packages to continue to work as much as possible

@h-vetinari
Copy link
Contributor Author

i don’t think any real urgency to bump numexpr or bottleneck mins
we generally try to allow packages to continue to work as much as possible

I only bumped them because anything lower is not compatible with numpy>=1.12 (you can check the respective builds to see that always something was failing due to unresolvable dependencies)

@@ -72,18 +70,9 @@ def _maybe_valid_colors(colors):
# check whether each character can be convertible to colors
maybe_color_cycle = _maybe_valid_colors(list(colors))
if maybe_single_color and maybe_color_cycle and len(colors) > 1:
# Special case for single str 'CN' match and convert to hex
# for supporting matplotlib < 2.0.0
if re.match(r'\AC[0-9]\Z', colors) and _mpl_ge_2_0_0():
Copy link
Member

Choose a reason for hiding this comment

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

Think we still need the condition to check the pattern match here, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It already said under else that "this may no longer be required". So I wanted to see if removing it still passes the test suite

@@ -854,7 +847,7 @@ def test_area_lim(self):
@pytest.mark.slow
def test_bar_colors(self):
import matplotlib.pyplot as plt
default_colors = self._maybe_unpack_cycler(plt.rcParams)
default_colors = [v['color'] for v in plt.rcParams['axes.prop_cycle']]
Copy link
Member

Choose a reason for hiding this comment

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

Any reason you decided to replace the method with a list comp? The couple calls would probably be more readable if left alone

@@ -72,18 +70,9 @@ def _maybe_valid_colors(colors):
# check whether each character can be convertible to colors
maybe_color_cycle = _maybe_valid_colors(list(colors))
if maybe_single_color and maybe_color_cycle and len(colors) > 1:
# Special case for single str 'CN' match and convert to hex
# for supporting matplotlib < 2.0.0
if re.match(r'\AC[0-9]\Z', colors) and _mpl_ge_2_0_0():
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It already said under else that "this may no longer be required". So I wanted to see if removing it still passes the test suite

@@ -510,20 +493,6 @@ def is_grid_on():
obj.plot(kind=kind, grid=True, **kws)
assert is_grid_on()

def _maybe_unpack_cycler(self, rcParams, field='color'):
"""
Compat layer for MPL 1.5 change to color cycle
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@WillAyd This sounded like it was only for compat. But I'll add it back in as convenience instead of the list comps

@h-vetinari h-vetinari force-pushed the bump_numpy branch 2 times, most recently from f4f5b46 to f81ad9f Compare October 10, 2018 06:51
We have updated our minimum supported versions of dependencies (:issue:`21242`).
If installed, we now require:

+-----------------+-----------------+----------+---------------+
Copy link
Contributor

Choose a reason for hiding this comment

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

remove the issue part here it is not necessary

@jbrockmendel
Copy link
Member

In core.ops there is a try/except for np.broadcast_to that can be simplified along with this PR.

arr = tz_replacer(arr)
# is_list_like
if hasattr(arr, '__iter__') and not \
isinstance(arr, string_and_binary_types):
Copy link
Member

Choose a reason for hiding this comment

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

Can you do this without the backslash?

@jbrockmendel
Copy link
Member

There's something wrong with the azure failure reporting (discovered by accident):
The last three runs reported success despite two failures in the Mac job

I've been troubleshooting the same problem here, please let me know if you figure it out

@h-vetinari
Copy link
Contributor Author

h-vetinari commented Oct 12, 2018

I understand now why no-one touched the matplotlib compat for a long time (e.g. _mpl_le_1_2_1 still around, while the lowest tested version prior to this PR was 1.4.3)...

In any case, I've now got a passing CI on all mpl builds again in 079bdaf (after the false positive from azure; there are no pins or changed code paths for matplotlib in Circle, which is lagging behind due to not cancelling on new pushes):
2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.2, 2.2.3, 3.0.0

Reverting the pins, then this thing should be done...

@TomAugspurger @jreback another quick look?

@jreback
Copy link
Contributor

jreback commented Oct 14, 2018

pls rebase

not you will have to rebase somewhat frequently until this is merged

@h-vetinari
Copy link
Contributor Author

note you will have to rebase somewhat frequently until this is merged

What's the hold-up on getting this merged soon?

@h-vetinari
Copy link
Contributor Author

PS. Can someone trigger the circleCI runs? not sure why they didn't start.

@jreback
Copy link
Contributor

jreback commented Oct 14, 2018

this. needs review for the plotting changes

Copy link
Contributor

@TomAugspurger TomAugspurger left a comment

Choose a reason for hiding this comment

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

Plotting changes look fine. Thanks for cleaning that up @h-vetinari.

@TomAugspurger
Copy link
Contributor

I don't see any way to trigger a circle build from their UI. Probably easiest to add an empty commit.

@jreback
Copy link
Contributor

jreback commented Oct 15, 2018

lgtm. @WillAyd if ok, pls accept, but after that @h-vetinari will need a rebase then, just before merging to make sure nothing has changed. (you can rebase now if you want).

@h-vetinari
Copy link
Contributor Author

Not much happened in the last 17h (3 commits), but ok.

# For mpl > 2.0 the format strings are controlled via rcparams
# so do not mess with them. For mpl < 2.0 change the second
# break point and add a musec break point
if _mpl_le_2_0_0():
Copy link
Member

Choose a reason for hiding this comment

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

Since mpl has a min version of 2.0.0 don't we still need this check?

Copy link
Contributor

Choose a reason for hiding this comment

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

That was probably being used incorrectly. I don't think it would apply to 2.0.0 but not 2.0.1.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made sure to test all available matplotlib versions, and while the removal of the code for 2.0.0 was an oversight, nothing in the test suite failed. As far as I can tell, 2.0.0 wasn't tested in the CI before, which is also the reason that several if-switches before this PR were strictly speaking wrong (when I removed the compat code in a way that just removed pre-2.0 branches, suddenly there were failures).

@jreback jreback merged commit aaa69d1 into pandas-dev:master Oct 15, 2018
@jreback
Copy link
Contributor

jreback commented Oct 15, 2018

thanks @h-vetinari

@h-vetinari
Copy link
Contributor Author

This was quite the effort I have to say. MPL has some really weird behaviour in that (e.g.) several times in test_datetimelike there's:

  • behaviour A in 2.0.0, 2.2.0 and 3.0.0
  • behaviour B in 2.0.1, 2.1.0, 2.2.2, 2.2.3.

Not 100% sure this is not overlaid with some numpy/system dependencies as well, but happy that right now everything passes and got merged.

@h-vetinari h-vetinari deleted the bump_numpy branch October 15, 2018 18:28
tm9k1 pushed a commit to tm9k1/pandas that referenced this pull request Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dependencies Required and optional dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DEPS: drop numpy < 1.12
7 participants