v2.0.2 breaks basic RST functionality.

[weaverba137]

Consider this docstring:

class SDSSMuNu(ac.BaseCoordinateFrame):
    """SDSS Great Circle Coordinates

    Attributes
    ----------
    stripe
        SDSS `Stripe Number`_ .
    node
        Node of the great circle with respect to the celestial equator.
        In SDSS, this is almost always RA = 95.0 degrees.
    incl
        Inclination of the great circle with respect to the celestial
        equator.
    phi
        Counter-clockwise position angle w.r.t. north for an arc
        in the +nu direction.

    .. _`Stripe Number`: http://www.sdss.org/dr14/help/glossary/#stripe

    Parameters
    ----------
    mu : :class:`~astropy.coordinates.Angle`
        Angle corresponding to longitude measured along a stripe.
    nu : :class:`~astropy.coordinates.Angle`
        Angle corresponding to latitude measured perpendicular to a stripe.

    Notes
    -----
    http://www.sdss.org/dr12/algorithms/surveycoords/
    """

After upgrading to v2.0.2, the Stripe Number link throws a warning:

.../pydl/pydlutils/coord.py:docstring of pydl.pydlutils.coord.SDSSMuNu:34: WARNING: Unknown target name: "stripe number".

And this warning causes python setup.py build_docs -w to fail.

[bsipocz]

The 2.0.2 helpers include an update to the bundled numpydoc and that is more strict to recieve a valid docstrings.

If you think it's an issue, please report upstream. https://github.com/numpy/numpydoc/

[eteq]

@weaverba137 - just to be sure: can you clarify if this is that the linking worked before, but now it doesn't, or that you're getting a warning now for something that's a legitimate warning?

(If it's the former, this should probably be re-opened, even if it still requires an upstream fix, as it's an actual use case problem for the helpers.)

[weaverba137]

@eteq, yes, before v2.0.2, it was working fine. Please see numpy/numpydoc#116 for further details.