TST: Fix numpy-dev failure

[pllim]

Description

This pull request is attempt to fix failing dev job. xref numpy/numpy#21711

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the Extra CI label.
• Is a change log needed? If yes, did the change log check pass? If no, add the no-changelog-entry-needed label. If this is a manual backport, use the skip-changelog-checks label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but astropy-bot check might be missing; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate backport-X.Y.x label(s) before merge.

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[WilliamJamieson]

I just attempted the same fix in astropy/asdf-astropy#94, and it looks like it failed just like this one did.

[WilliamJamieson]

Still no luck

[pllim]

Yeah, I'll have to report back to numpy. I dunno why they exact pin setuptools.

[mattip]

The installation is building numpy from source rather than installing a binary wheel. Somehow using the source from https://pypi.anaconda.org/scipy-wheels-nightly then confuses pip, and it tries to install the depenencies from that index as well, which fails because of course there is no setuptools there.

[mattip]

Maybe another victim of pypa/pip#9140. Is there a way to add --only-binary to the numpy install step?

[mattip]

Sorry, I think it needs to be --only-binary :all:

[mattip]

Yay. On to the next failure: the interface for unit's concatenate is not quite right. Tests are failing with TypeError: concatenate() got an unexpected keyword argument 'dtype'. In NumPy, concatenate got that keyword in 1.20...

[saimn]

Thanks for the help @mattip !
cc @mhvk for the concatenate issue.

[pllim]

What is coordinates doing here and why is it only breaking in the dev version of numpy? cc @eteq , @adrn , and @eerovaher too...

astropy/astropy/coordinates/tests/test_transformations.py

Lines 262 to 266 in bbee7b4

	r.CartesianRepresentation(5, 6, 7, unit=u.pc,
	differentials=r.CartesianDifferential(8, 9, 10,
	unit=u.pc/u.Myr))
	.represent_as(r.CylindricalRepresentation, r.CylindricalDifferential)
	])

_ ERROR collecting .../astropy/coordinates/tests/test_transformations.py _
.../astropy/coordinates/tests/test_transformations.py:262: in <module>
    r.CartesianRepresentation(5, 6, 7, unit=u.pc,
.../astropy/coordinates/representation.py:877: in represent_as
    new_rep._differentials = self._re_represent_differentials(
.../astropy/coordinates/representation.py:827: in _re_represent_differentials
    new_diffs[k] = diff.represent_as(differential_class[k],
.../astropy/coordinates/representation.py:2607: in represent_as
    return other_class.from_cartesian(self_cartesian, base)
.../astropy/coordinates/representation.py:2583: in from_cartesian
    return cls(*(other.dot(e / base_sf[component])
.../astropy/coordinates/representation.py:2583: in <genexpr>
    return cls(*(other.dot(e / base_sf[component])
.../astropy/coordinates/representation.py:1488: in dot
    return erfa_ufunc.pdp(self.get_xyz(xyz_axis=-1),
.../astropy/coordinates/representation.py:1351: in get_xyz
    return np.stack([self._x, self._y, self._z], axis=xyz_axis)
<__array_function__ internals>:180: in stack
    ???
.../astropy/units/quantity.py:1690: in __array_function__
    return super().__array_function__(function, types, args, kwargs)
.../numpy/core/shape_base.py:469: in stack
    return _nx.concatenate(expanded_arrays, axis=axis, out=out,
<__array_function__ internals>:180: in concatenate
    ???
.../astropy/units/quantity.py:1695: in __array_function__
    args, kwargs, unit, out = function_helper(*args, **kwargs)
E   TypeError: concatenate() got an unexpected keyword argument 'dtype'

[pllim]

Could it be due to numpy/numpy#21627 ?

[mhvk]

Yes, seems likely! I'll try to look at it later today.

[mhvk]

@pllim - I just pushed what should be a fix for the concatenate issue directly to your branch. Hopefully, it will work!

@mattip - thanks for diagnosing the problem! I guess when I wrote the array function implementation I had been too lazy to code for possible future extension...

[mhvk]

p.s. Added the bug label since this fixes a bug with all numpy >=1.20.

[pllim]

Nooooo, matplotlib wants to join the fun too...

matplotlib._api.deprecation.MatplotlibDeprecationWarning: The checkdep_usetex function was deprecated in Matplotlib 3.6 and will be removed two minor releases later. Use Vendor the code instead.

[mhvk]

@pllim - is it perhaps easier if I split off my fix? After all, it includes tests that will fail on numpy 1.20 too. What do you think?

[pllim]

@mhvk , up to you. Thanks!

[pllim]

Looks like matplotlib took that whole API private but I dunno what they mean by "vendor the code," so I asked at matplotlib/matplotlib#23244

[mhvk]

OK, probably easier with it separated out given the matplotlib errors - see #13323

[pllim]

I dropped the changes that went into #13323 , removed usage of matplotlib.checkdep_usetex() (we can ponder how/if we want to "vendor the code" later), and cleaned up the commit history.

[pllim]

Should we get this in and I can open up follow up issue about matplotlib? (see #13326)

[pllim]

It's Friday night, so #yolo